+++ /dev/null
-This is doc/cpp.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/cpp.texi.
-
-Copyright (C) 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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
-
-\1f
-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, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-
-\1f
-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=c89' or `-std=c99' 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::
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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".
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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 `/usr/include/g++-v3', 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::.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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"
-
-\1f
-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.
-
-\1f
-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),
- ...
- };
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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. A fully conforming
- implementation of the 1998 C++ standard will define this macro to
- `199711L'. The GNU C++ compiler is not yet fully conforming, so
- it uses `1' instead. It is hoped to complete the implementation
- of standard C++ in the near future.
-
-`__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 a Objective-C compiler.
-
-`__ASSEMBLER__'
- This macro is defined with value 1 when preprocessing assembly
- language.
-
-
-\1f
-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, 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 gnu89 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 gnu89 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 gnu89 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__'
- These macros are defined to the correct underlying types for the
- `size_t', `ptrdiff_t', `wchar_t', `wint_t', `intmax_t', and
- `uintmax_t' typedefs, respectively. They exist to make the
- standard header files `stddef.h' and `wchar.h' work correctly.
- You should not use these macros directly; instead, include the
- appropriate headers and use the typedefs.
-
-`__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__'
-`__INTMAX_MAX__'
- Defined to the maximum value of the `signed char', `wchar_t',
- `signed short', `signed int', `signed long', `signed long long',
- and `intmax_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.
-
-`__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'.
-
-`__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.
-
-`__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.
-
-\1f
-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 the constant 1, 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'.
-
-\1f
-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' `^='
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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))
-
-\1f
-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.
-
-\1f
-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').
-
-\1f
-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.
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-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 `/*'.
-
-\1f
-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(UNALIGNED_INT_ASM_OP) && defined(DWARF2_DEBUGGING_INFO)
- #error "DWARF2_DEBUGGING_INFO requires UNALIGNED_INT_ASM_OP."
- #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.
-
-\1f
-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
-
- #line 1 "../src/gram.y"
- #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.
-
-\1f
-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.
-
-`#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::.
-
-
-\1f
-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.
-
- Both `#ident' and `#sccs' are deprecated extensions.
-
- 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.
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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 values 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.
-
-
-\1f
-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.
-
-
-\1f
-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. However, 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::.
-
-\1f
-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.)
-
-
-\1f
-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:
- `iso9899:1990'
- `c89'
- The ISO C standard from 1990. `c89' is the customary
- shorthand for this version of the standard.
-
- The `-ansi' option is equivalent to `-std=c89'.
-
- `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.
-
- `gnu89'
- The 1990 C standard plus GNU extensions. This is the default.
-
- `gnu99'
- `gnu9x'
- The 1999 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. 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++.
-
-`-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.
-
-`-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
- Debugging Options: (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.
-
-\1f
-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::.
-
-\1f
-File: cpp.info, Node: GNU Free Documentation License, Next: Index of Directives, Prev: Environment Variables, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-File: cpp.info, Node: Index of Directives, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
-
-Index of Directives
-*******************
-
-\0\b[index\0\b]
-* 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 53)
-* #pragma GCC poison: Pragmas. (line 65)
-* #pragma GCC system_header <1>: Pragmas. (line 92)
-* #pragma GCC system_header: System Headers. (line 31)
-* #sccs: Other Directives. (line 6)
-* #unassert: Obsolete Features. (line 59)
-* #undef: Undefining and Redefining Macros.
- (line 6)
-* #warning: Diagnostics. (line 27)
-
-\1f
-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 `--'.
-
-\0\b[index\0\b]
-* Menu:
-
-* A: Invocation. (line 522)
-* ansi: Invocation. (line 308)
-* C: Invocation. (line 581)
-* C_INCLUDE_PATH: Environment Variables.
- (line 16)
-* CPATH: Environment Variables.
- (line 15)
-* CPLUS_INCLUDE_PATH: Environment Variables.
- (line 17)
-* D: Invocation. (line 39)
-* dD: Invocation. (line 554)
-* DEPENDENCIES_OUTPUT: Environment Variables.
- (line 44)
-* dI: Invocation. (line 563)
-* dM: Invocation. (line 538)
-* dN: Invocation. (line 560)
-* dU: Invocation. (line 567)
-* fdirectives-only: Invocation. (line 430)
-* fdollars-in-identifiers: Invocation. (line 452)
-* fexec-charset: Invocation. (line 479)
-* fextended-identifiers: Invocation. (line 455)
-* finput-charset: Invocation. (line 492)
-* fno-show-column: Invocation. (line 517)
-* fno-working-directory: Invocation. (line 502)
-* fpreprocessed: Invocation. (line 460)
-* ftabstop: Invocation. (line 473)
-* fwide-exec-charset: Invocation. (line 484)
-* fworking-directory: Invocation. (line 502)
-* H: Invocation. (line 626)
-* help: Invocation. (line 618)
-* I: Invocation. (line 71)
-* I-: Invocation. (line 345)
-* idirafter: Invocation. (line 387)
-* imacros: Invocation. (line 378)
-* imultilib: Invocation. (line 410)
-* include: Invocation. (line 367)
-* iprefix: Invocation. (line 394)
-* iquote: Invocation. (line 422)
-* isysroot: Invocation. (line 406)
-* isystem: Invocation. (line 414)
-* iwithprefix: Invocation. (line 400)
-* iwithprefixbefore: Invocation. (line 400)
-* M: Invocation. (line 180)
-* MD: Invocation. (line 269)
-* MF: Invocation. (line 215)
-* MG: Invocation. (line 224)
-* MM: Invocation. (line 205)
-* MMD: Invocation. (line 285)
-* MP: Invocation. (line 234)
-* MQ: Invocation. (line 260)
-* MT: Invocation. (line 246)
-* nostdinc: Invocation. (line 357)
-* nostdinc++: Invocation. (line 362)
-* o: Invocation. (line 82)
-* OBJC_INCLUDE_PATH: Environment Variables.
- (line 18)
-* P: Invocation. (line 574)
-* pedantic: Invocation. (line 170)
-* pedantic-errors: Invocation. (line 175)
-* remap: Invocation. (line 613)
-* std=: Invocation. (line 308)
-* SUNPRO_DEPENDENCIES: Environment Variables.
- (line 60)
-* target-help: Invocation. (line 618)
-* traditional-cpp: Invocation. (line 606)
-* trigraphs: Invocation. (line 610)
-* U: Invocation. (line 62)
-* undef: Invocation. (line 66)
-* v: Invocation. (line 622)
-* version: Invocation. (line 635)
-* w: Invocation. (line 166)
-* Wall: Invocation. (line 88)
-* Wcomment: Invocation. (line 96)
-* Wcomments: Invocation. (line 96)
-* Wendif-labels: Invocation. (line 143)
-* Werror: Invocation. (line 156)
-* Wsystem-headers: Invocation. (line 160)
-* Wtraditional: Invocation. (line 113)
-* Wtrigraphs: Invocation. (line 101)
-* Wundef: Invocation. (line 119)
-* Wunused-macros: Invocation. (line 124)
-* x: Invocation. (line 292)
-
-\1f
-File: cpp.info, Node: Concept Index, Prev: Option Index, Up: Top
-
-Concept Index
-*************
-
-\0\b[index\0\b]
-* Menu:
-
-* # operator: Stringification. (line 6)
-* ## operator: Concatenation. (line 6)
-* _Pragma: Pragmas. (line 25)
-* alternative tokens: Tokenization. (line 106)
-* 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 85)
-* character set, execution: Invocation. (line 479)
-* character set, input: Invocation. (line 492)
-* character set, wide execution: Invocation. (line 484)
-* 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, make: Invocation. (line 180)
-* diagnostic: Diagnostics. (line 6)
-* differences from previous versions: Differences from previous versions.
- (line 6)
-* digraphs: Tokenization. (line 106)
-* 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 85)
-* identifiers: Tokenization. (line 34)
-* 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 180)
-* 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 17)
-* numbers: Tokenization. (line 61)
-* object-like macro: Object-like Macros. (line 6)
-* options: Invocation. (line 38)
-* options, grouping: Invocation. (line 34)
-* other tokens: Tokenization. (line 120)
-* 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 61)
-* preprocessing tokens: Tokenization. (line 6)
-* prescan of macro arguments: Argument Prescan. (line 6)
-* problems with macros: Macro Pitfalls. (line 6)
-* punctuators: Tokenization. (line 106)
-* 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 85)
-* string literals: Tokenization. (line 85)
-* stringification: Stringification. (line 6)
-* symbolic constants: Object-like Macros. (line 6)
-* system header files <1>: System Headers. (line 6)
-* system header files: Header Files. (line 13)
-* 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)
-
-
-\1f
-Tag Table:
-Node: Top\7f1091
-Node: Overview\7f3805
-Node: Character sets\7f6626
-Ref: Character sets-Footnote-1\7f8809
-Node: Initial processing\7f8990
-Ref: trigraphs\7f10549
-Node: Tokenization\7f14751
-Ref: Tokenization-Footnote-1\7f21887
-Node: The preprocessing language\7f21998
-Node: Header Files\7f24876
-Node: Include Syntax\7f26792
-Node: Include Operation\7f28429
-Node: Search Path\7f30277
-Node: Once-Only Headers\7f33467
-Node: Alternatives to Wrapper #ifndef\7f35126
-Node: Computed Includes\7f36869
-Node: Wrapper Headers\7f40027
-Node: System Headers\7f42453
-Node: Macros\7f44503
-Node: Object-like Macros\7f45644
-Node: Function-like Macros\7f49234
-Node: Macro Arguments\7f50850
-Node: Stringification\7f54995
-Node: Concatenation\7f58201
-Node: Variadic Macros\7f61309
-Node: Predefined Macros\7f66096
-Node: Standard Predefined Macros\7f66684
-Node: Common Predefined Macros\7f72620
-Node: System-specific Predefined Macros\7f85530
-Node: C++ Named Operators\7f87551
-Node: Undefining and Redefining Macros\7f88515
-Node: Directives Within Macro Arguments\7f90619
-Node: Macro Pitfalls\7f92167
-Node: Misnesting\7f92700
-Node: Operator Precedence Problems\7f93812
-Node: Swallowing the Semicolon\7f95678
-Node: Duplication of Side Effects\7f97701
-Node: Self-Referential Macros\7f99884
-Node: Argument Prescan\7f102293
-Node: Newlines in Arguments\7f106047
-Node: Conditionals\7f106998
-Node: Conditional Uses\7f108828
-Node: Conditional Syntax\7f110186
-Node: Ifdef\7f110506
-Node: If\7f113667
-Node: Defined\7f115971
-Node: Else\7f117254
-Node: Elif\7f117824
-Node: Deleted Code\7f119113
-Node: Diagnostics\7f120360
-Node: Line Control\7f121977
-Node: Pragmas\7f125781
-Node: Other Directives\7f130051
-Node: Preprocessor Output\7f131158
-Node: Traditional Mode\7f134359
-Node: Traditional lexical analysis\7f135417
-Node: Traditional macros\7f137920
-Node: Traditional miscellany\7f141722
-Node: Traditional warnings\7f142719
-Node: Implementation Details\7f144916
-Node: Implementation-defined behavior\7f145537
-Ref: Identifier characters\7f146289
-Node: Implementation limits\7f149364
-Node: Obsolete Features\7f152038
-Node: Differences from previous versions\7f154875
-Node: Invocation\7f159083
-Ref: Wtrigraphs\7f163535
-Ref: dashMF\7f168310
-Ref: fdollars-in-identifiers\7f177693
-Node: Environment Variables\7f185856
-Node: GNU Free Documentation License\7f188822
-Node: Index of Directives\7f211255
-Node: Option Index\7f213189
-Node: Concept Index\7f219373
-\1f
-End Tag Table
+++ /dev/null
-This is doc/cppinternals.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/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 2000, 2001, 2002, 2004, 2005, 2006, 2007 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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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).
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-File: cppinternals.info, Node: Concept Index, Prev: Files, Up: Top
-
-Concept Index
-*************
-
-\0\b[index\0\b]
-* Menu:
-
-* assertions: Hash Nodes. (line 6)
-* controlling macros: Guard Macros. (line 6)
-* escaped newlines: Lexer. (line 6)
-* 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 6)
-* 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 192)
-* token spacing: Token Spacing. (line 6)
-
-
-\1f
-Tag Table:
-Node: Top\7f971
-Node: Conventions\7f2656
-Node: Lexer\7f3598
-Ref: Invalid identifiers\7f11511
-Ref: Lexing a line\7f13460
-Node: Hash Nodes\7f18233
-Node: Macro Expansion\7f21112
-Node: Token Spacing\7f30059
-Node: Line Numbering\7f35919
-Node: Guard Macros\7f40004
-Node: Files\7f44795
-Node: Concept Index\7f48261
-\1f
-End Tag Table
+++ /dev/null
-This is doc/gcc.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/gcc.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-END-INFO-DIR-ENTRY
- This file documents the use of the GNU compilers.
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-
-
-\1f
-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.4.3. 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 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 find suppliers of support for 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.
-
-\1f
-File: gcc.info, Node: G++ and GCC, Next: Standards, Prev: Top, 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, and Ada.
-
- 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.
-
-\1f
-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=c89' 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 incomplete support
-for this standard version; see
-`http://gcc.gnu.org/gcc-4.4/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.
-
- 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=gnu89' (for C89 with GNU extensions) or
-`-std=gnu99' (for C99 with GNU extensions). The default, if no C
-language dialect options are given, is `-std=gnu89'; this will change to
-`-std=gnu99' in some future release when the C99 support is complete.
-Some features that are part of the C99 standard are accepted as
-extensions in C89 mode.
-
- 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>'; and in C99,
-also those in `<stdbool.h>' and `<stdint.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; 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 ISO C++ standard (1998) and contains experimental
-support for the upcoming ISO C++ standard (200x).
-
- 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' or `-std=c++98'; 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).
-
- The ISO C++ committee is working on a new ISO C++ standard, dubbed
-C++0x, that is intended to be published by 2009. C++0x contains several
-changes to the C++ language, some of which have been implemented in an
-experimental C++0x mode in GCC. The C++0x mode in GCC tracks the draft
-working paper for the C++0x standard; the latest working paper is
-available on the ISO C++ committee's web site at
-`http://www.open-std.org/jtc1/sc22/wg21/'. For information regarding
-the C++0x features available in the experimental C++0x mode, see
-`http://gcc.gnu.org/gcc-4.3/cxx0x_status.html'. To select this standard
-in GCC, use the option `-std=c++0x'; 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).
-
- 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++0x' (for
-C++0x 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
-===========================================
-
-There is no formal written standard for Objective-C or Objective-C++.
-The most authoritative manual is "Object-Oriented Programming and the
-Objective-C Language", available at a number of web sites:
-
- *
- `http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/'
- is a recent (and periodically updated) version;
-
- * `http://www.toodarkpark.org/computers/objc/' is an older example;
-
- * `http://www.gnustep.org' and `http://gcc.gnu.org/readings.html'
- have additional useful information.
-
- *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.
-
-\1f
-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'
-would be `-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.
-* Running Protoize:: Automatically adding or removing function prototypes.
-
-\1f
-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 -combine -pipe -pass-exit-codes
- -x LANGUAGE -v -### --help[=CLASS[,...]] --target-help
- --version -wrapper@FILE
-
-_C Language Options_
- *Note Options Controlling C Dialect: C Dialect Options.
- -ansi -std=STANDARD -fgnu89-inline
- -aux-info FILENAME
- -fno-asm -fno-builtin -fno-builtin-FUNCTION
- -fhosted -ffreestanding -fopenmp -fms-extensions
- -trigraphs -no-integrated-cpp -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
- -fconserve-space -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 -fno-operator-names
- -fno-optional-diags -fpermissive
- -frepo -fno-rtti -fstats -ftemplate-depth-N
- -fno-threadsafe-statics -fuse-cxa-atexit -fno-weak -nostdinc++
- -fno-default-inline -fvisibility-inlines-hidden
- -fvisibility-ms-compat
- -Wabi -Wctor-dtor-privacy
- -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-call-cxx-cdtors
- -fobjc-direct-dispatch
- -fobjc-exceptions
- -fobjc-gc
- -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-show-option
-
-_Warning Options_
- *Note Options to Request or Suppress Warnings: Warning Options.
- -fsyntax-only -pedantic -pedantic-errors
- -w -Wextra -Wall -Waddress -Waggregate-return -Warray-bounds
- -Wno-attributes -Wno-builtin-macro-redefined
- -Wc++-compat -Wc++0x-compat -Wcast-align -Wcast-qual
- -Wchar-subscripts -Wclobbered -Wcomment
- -Wconversion -Wcoverage-mismatch -Wno-deprecated
- -Wno-deprecated-declarations -Wdisabled-optimization
- -Wno-div-by-zero -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 -Wignored-qualifiers
- -Wimplicit -Wimplicit-function-declaration -Wimplicit-int
- -Winit-self -Winline
- -Wno-int-to-pointer-cast -Wno-invalid-offsetof
- -Winvalid-pch -Wlarger-than=LEN -Wunsafe-loop-optimizations
- -Wlogical-op -Wlong-long
- -Wmain -Wmissing-braces -Wmissing-field-initializers
- -Wmissing-format-attribute -Wmissing-include-dirs
- -Wmissing-noreturn -Wno-mudflap
- -Wno-multichar -Wnonnull -Wno-overflow
- -Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded
- -Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format
- -Wpointer-arith -Wno-pointer-to-int-cast
- -Wredundant-decls
- -Wreturn-type -Wsequence-point -Wshadow
- -Wsign-compare -Wsign-conversion -Wstack-protector
- -Wstrict-aliasing -Wstrict-aliasing=n
- -Wstrict-overflow -Wstrict-overflow=N
- -Wswitch -Wswitch-default -Wswitch-enum -Wsync-nand
- -Wsystem-headers -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized
- -Wunknown-pragmas -Wno-pragmas -Wunreachable-code
- -Wunused -Wunused-function -Wunused-label -Wunused-parameter
- -Wunused-value -Wunused-variable
- -Wvariadic-macros -Wvla
- -Wvolatile-register-var -Wwrite-strings
-
-_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
- -fdbg-cnt-list -fdbg-cnt=COUNTER-VALUE-LIST
- -fdump-noaddr -fdump-unnumbered
- -fdump-translation-unit[-N]
- -fdump-class-hierarchy[-N]
- -fdump-ipa-all -fdump-ipa-cgraph -fdump-ipa-inline
- -fdump-statistics
- -fdump-tree-all
- -fdump-tree-original[-N]
- -fdump-tree-optimized[-N]
- -fdump-tree-cfg -fdump-tree-vcg -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-mudflap[-N]
- -fdump-tree-dom[-N]
- -fdump-tree-dse[-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-fre[-N]
- -fdump-tree-vrp[-N]
- -ftree-vectorizer-verbose=N
- -fdump-tree-storeccp[-N]
- -feliminate-dwarf2-dups -feliminate-unused-debug-types
- -feliminate-unused-debug-symbols -femit-class-debug-always
- -fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs
- -frandom-seed=STRING -fsched-verbose=N
- -fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose
- -ftest-coverage -ftime-report -fvar-tracking
- -g -gLEVEL -gcoff -gdwarf-2
- -ggdb -gstabs -gstabs+ -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-prog-name=PROGRAM -print-search-dirs -Q
- -print-sysroot -print-sysroot-headers-suffix
- -save-temps -time
-
-_Optimization Options_
- *Note Options that Control Optimization: Optimize Options.
- -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 -fconserve-stack -fcprop-registers -fcrossjumping
- -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules -fcx-limited-range
- -fdata-sections -fdce -fdce
- -fdelayed-branch -fdelete-null-pointer-checks -fdse -fdse
- -fearly-inlining -fexpensive-optimizations -ffast-math
- -ffinite-math-only -ffloat-store -fforward-propagate
- -ffunction-sections -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm
- -fgcse-sm -fif-conversion -fif-conversion2 -findirect-inlining
- -finline-functions -finline-functions-called-once -finline-limit=N
- -finline-small-functions -fipa-cp -fipa-cp-clone -fipa-matrix-reorg -fipa-pta
- -fipa-pure-const -fipa-reference -fipa-struct-reorg
- -fipa-type-escape -fira-algorithm=ALGORITHM
- -fira-region=REGION -fira-coalesce -fno-ira-share-save-slots
- -fno-ira-share-spill-slots -fira-verbose=N
- -fivopts -fkeep-inline-functions -fkeep-static-consts
- -floop-block -floop-interchange -floop-strip-mine
- -fmerge-all-constants -fmerge-constants -fmodulo-sched
- -fmodulo-sched-allow-regmoves -fmove-loop-invariants -fmudflap
- -fmudflapir -fmudflapth -fno-branch-count-reg -fno-default-inline
- -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-register-move -foptimize-sibling-calls
- -fpeel-loops -fpredictive-commoning -fprefetch-loop-arrays
- -fprofile-correction -fprofile-dir=PATH -fprofile-generate
- -fprofile-generate=PATH
- -fprofile-use -fprofile-use=PATH -fprofile-values
- -freciprocal-math -fregmove -frename-registers -freorder-blocks
- -freorder-blocks-and-partition -freorder-functions
- -frerun-cse-after-loop -freschedule-modulo-scheduled-loops
- -frounding-math -frtl-abstract-sequences -fsched2-use-superblocks
- -fsched2-use-traces -fsched-spec-load -fsched-spec-load-dangerous
- -fsched-stalled-insns-dep[=N] -fsched-stalled-insns[=N]
- -fschedule-insns -fschedule-insns2 -fsection-anchors -fsee
- -fselective-scheduling -fselective-scheduling2
- -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
- -fsignaling-nans -fsingle-precision-constant -fsplit-ivs-in-unroller
- -fsplit-wide-types -fstack-protector -fstack-protector-all
- -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftracer
- -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop
- -ftree-copyrename -ftree-dce
- -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
- -ftree-loop-distribution
- -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize
- -ftree-parallelize-loops=N -ftree-pre -ftree-reassoc
- -ftree-sink -ftree-sra -ftree-switch-conversion
- -ftree-ter -ftree-vect-loop-version -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
- --param NAME=VALUE
- -O -O0 -O1 -O2 -O3 -Os
-
-_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 -fworking-directory -remap
- -trigraphs -undef -UMACRO -Wp,OPTION
- -Xpreprocessor OPTION
-
-_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 -shared -shared-libgcc -symbolic
- -T SCRIPT -Wl,OPTION -Xlinker OPTION
- -u SYMBOL
-
-_Directory Options_
- *Note Options for Directory Search: Directory Options.
- -BPREFIX -IDIR -iquoteDIR -LDIR
- -specs=FILE -I- --sysroot=DIR
-
-_Target Options_
- *Note Target Options::.
- -V VERSION -b MACHINE
-
-_Machine Dependent Options_
- *Note Hardware Models and Configurations: Submodel Options.
-
- _ARC Options_
- -EB -EL
- -mmangle-cpu -mcpu=CPU -mtext=TEXT-SECTION
- -mdata=DATA-SECTION -mrodata=READONLY-DATA-SECTION
-
- _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 -msoft-float -mhard-float -mfpe
- -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
- -mcirrus-fix-invalid-insns -mno-cirrus-fix-invalid-insns
- -mpoke-function-name
- -mthumb -marm
- -mtpcs-frame -mtpcs-leaf-frame
- -mcaller-super-interworking -mcallee-super-interworking
- -mtp=NAME
- -mword-relocations
- -mfix-cortex-m3-ldrd
-
- _AVR Options_
- -mmcu=MCU -msize -mno-interrupts
- -mcall-prologues -mno-tablejump -mtiny-stack -mint8
-
- _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
-
- _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
-
- _CRX Options_
- -mmac -mpush-args
-
- _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 -malpha-as -mgas
- -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
-
- _DEC Alpha/VMS Options_
- -mvms-return-codes
-
- _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_
- -muclibc
-
- _H8/300 Options_
- -mrelax -mh -ms -mn -mint32 -malign-300
-
- _HPPA Options_
- -march=ARCHITECTURE-TYPE
- -mbig-switch -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-big-switch -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
- -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 -mrecip
- -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx
- -maes -mpclmul
- -msse4a -m3dnow -mpopcnt -mabm -msse5
- -mthreads -mno-align-stringops -minline-all-stringops
- -minline-stringops-dynamically -mstringop-strategy=ALG
- -mpush-args -maccumulate-outgoing-args -m128bit-long-double
- -m96bit-long-double -mregparm=NUM -msseregparm
- -mveclibabi=TYPE -mpc32 -mpc64 -mpc80 -mstackrealign
- -momit-leaf-frame-pointer -mno-red-zone -mno-tls-direct-seg-refs
- -mcmodel=CODE-MODEL
- -m32 -m64 -mlarge-data-threshold=NUM
- -mfused-madd -mno-fused-madd -msse2avx
-
- _IA-64 Options_
- -mbig-endian -mlittle-endian -mgnu-as -mgnu-ld -mno-pic
- -mvolatile-asm-stop -mregister-names -mno-sdata
- -mconstant-gp -mauto-pic -minline-float-divide-min-latency
- -minline-float-divide-max-throughput
- -minline-int-divide-min-latency
- -minline-int-divide-max-throughput
- -minline-sqrt-min-latency -minline-sqrt-max-throughput
- -mno-dwarf2-asm -mearly-stop-bits
- -mfixed-range=REGISTER-RANGE -mtls-size=TLS-SIZE
- -mtune=CPU-TYPE -mt -pthread -milp32 -mlp64
- -mno-sched-br-data-spec -msched-ar-data-spec -mno-sched-control-spec
- -msched-br-in-data-spec -msched-ar-in-data-spec -msched-in-control-spec
- -msched-ldc -mno-sched-control-ldc -mno-sched-spec-verbose
- -mno-sched-prefer-non-data-spec-insns
- -mno-sched-prefer-non-control-spec-insns
- -mno-sched-count-spec-in-critical-path
-
- _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
-
- _M68hc1x Options_
- -m6811 -m6812 -m68hc11 -m68hc12 -m68hcs12
- -mauto-incdec -minmax -mlong-calls -mshort
- -msoft-reg-count=COUNT
-
- _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
-
- _MIPS Options_
- -EL -EB -march=ARCH -mtune=ARCH
- -mips1 -mips2 -mips3 -mips4 -mips32 -mips32r2
- -mips64 -mips64r2
- -mips16 -mno-mips16 -mflip-mips16
- -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
- -msingle-float -mdouble-float -mdsp -mno-dsp -mdspr2 -mno-dspr2
- -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 -mfused-madd -mno-fused-madd -nocpp
- -mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
- -mfix-r10000 -mno-fix-r10000 -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
-
- _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
- -mam33 -mno-am33
- -mam33-2 -mno-am33-2
- -mreturn-pointer-on-d0
- -mno-crt0 -mrelax
-
- _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
- -msplit -mno-split -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.
-
- _RS/6000 and PowerPC Options_
- -mcpu=CPU-TYPE
- -mtune=CPU-TYPE
- -mpower -mno-power -mpower2 -mno-power2
- -mpowerpc -mpowerpc64 -mno-powerpc
- -maltivec -mno-altivec
- -mpowerpc-gpopt -mno-powerpc-gpopt
- -mpowerpc-gfxopt -mno-powerpc-gfxopt
- -mmfcrf -mno-mfcrf -mpopcntb -mno-popcntb -mfprnd -mno-fprnd
- -mcmpb -mno-cmpb -mmfpgpr -mno-mfpgpr -mhard-dfp -mno-hard-dfp
- -mnew-mnemonics -mold-mnemonics
- -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
- -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
- -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
-
- _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
-
- _Score Options_
- -meb -mel
- -mnhwloop
- -muls
- -mmac
- -mscore5 -mscore5u -mscore7 -mscore7d
-
- _SH Options_
- -m1 -m2 -m2e -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 -mbitops -misize -minline-ic_invalidate -mpadstruct -mspace
- -mprefergot -musermode -multcost=NUMBER -mdiv=STRATEGY
- -mdivsi3_libfunc=NAME -mfixed-range=REGISTER-RANGE
- -madjust-unroll -mindexed-addressing -mgettrcost=NUMBER -mpt-fixed
- -minvalid-symbols
-
- _SPARC Options_
- -mcpu=CPU-TYPE
- -mtune=CPU-TYPE
- -mcmodel=CODE-MODEL
- -m32 -m64 -mapp-regs -mno-app-regs
- -mfaster-structs -mno-faster-structs
- -mfpu -mno-fpu -mhard-float -msoft-float
- -mhard-quad-float -msoft-quad-float
- -mimpure-text -mno-impure-text -mlittle-endian
- -mstack-bias -mno-stack-bias
- -munaligned-doubles -mno-unaligned-doubles
- -mv8plus -mno-v8plus -mvis -mno-vis
- -threads -pthreads -pthread
-
- _SPU Options_
- -mwarn-reloc -merror-reloc
- -msafe-dma -munsafe-dma
- -mbranch-hints
- -msmall-mem -mlarge-mem -mstdmain
- -mfixed-range=REGISTER-RANGE
-
- _System V Options_
- -Qy -Qn -YP,PATHS -Ym,DIR
-
- _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
- -mv850e1
- -mv850e
- -mv850 -mbig-switch
-
- _VAX Options_
- -mg -mgnu -munix
-
- _VxWorks Options_
- -mrtp -non-static -Bstatic -Bdynamic
- -Xbind-lazy -Xbind-now
-
- _x86-64 Options_ See i386 and x86-64 Options.
-
- _i386 and x86-64 Windows Options_
- -mconsole -mcygwin -mno-cygwin -mdll
- -mnop-fun-dllimport -mthread -mwin32 -mwindows
-
- _Xstormy16 Options_
- -msim
-
- _Xtensa Options_
- -mconst16 -mno-const16
- -mfused-madd -mno-fused-madd
- -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 -funwind-tables
- -fasynchronous-unwind-tables
- -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 -fargument-alias -fargument-noalias
- -fargument-noalias-global -fargument-noalias-anything
- -fleading-underscore -ftls-model=MODEL
- -ftrapv -fwrapv -fbounds-check
- -fvisibility
-
-
-* Menu:
-
-* Overall Options:: Controlling the kind of output:
- an executable, object files, assembler files,
- or preprocessed source.
-* C Dialect Options:: Controlling the variant of C language compiled.
-* C++ Dialect Options:: Variations on C++.
-* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
- and Objective-C++.
-* Language Independent Options:: Controlling how diagnostics should be
- formatted.
-* Warning Options:: How picky should the compiler be?
-* Debugging Options:: Symbol tables, measurements, and debugging dumps.
-* Optimize Options:: How much optimization?
-* Preprocessor Options:: Controlling header files and macro definitions.
- Also, getting dependency information for Make.
-* Assembler Options:: Passing options to the assembler.
-* Link Options:: Specifying libraries and so on.
-* Directory Options:: Where to find header files and libraries.
- Where to find the compiler executable files.
-* Spec Files:: How to pass switches to sub-processes.
-* Target Options:: Running a cross-compiler, or an old version of GCC.
-
-\1f
-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 which must be preprocessed.
-
-`FILE.i'
- C source code which should not be preprocessed.
-
-`FILE.ii'
- C++ source code which 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 which 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 which should not be preprocessed.
-
-`FILE.h'
- C, C++, Objective-C or Objective-C++ header file to be turned into
- a precompiled header.
-
-`FILE.cc'
-`FILE.cp'
-`FILE.cxx'
-`FILE.cpp'
-`FILE.CPP'
-`FILE.c++'
-`FILE.C'
- C++ source code which 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 which must be preprocessed.
-
-`FILE.mii'
- Objective-C++ source code which 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.
-
-`FILE.f'
-`FILE.for'
-`FILE.ftn'
- Fixed form Fortran source code which should not be preprocessed.
-
-`FILE.F'
-`FILE.FOR'
-`FILE.fpp'
-`FILE.FPP'
-`FILE.FTN'
- Fixed form Fortran source code which must be preprocessed (with
- the traditional preprocessor).
-
-`FILE.f90'
-`FILE.f95'
-`FILE.f03'
-`FILE.f08'
- Free form Fortran source code which should not be preprocessed.
-
-`FILE.F90'
-`FILE.F95'
-`FILE.F03'
-`FILE.F08'
- Free form Fortran source code which must be preprocessed (with the
- traditional preprocessor).
-
-`FILE.ads'
- Ada source code file which 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 which 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 c-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
- 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 will exit 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 will instead return
- with numerically highest error produced by any phase that returned
- an error indication. The C, C++, and Fortran frontends 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 which don't require preprocessing are ignored.
-
-`-o FILE'
- Place output in file FILE. This applies regardless 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 all command
- arguments are quoted. 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.
-
-`-combine'
- If you are compiling multiple source files, this option tells the
- driver to pass all the source files to the compiler at once (for
- those languages for which the compiler can handle this). This
- will allow intermodule analysis (IMA) to be performed by the
- compiler. Currently the only language for which this is supported
- is C. If you pass source files for multiple languages to the
- driver, using this option, the driver will invoke the compiler(s)
- that support IMA once each, passing each compiler all the source
- files appropriate for it. For those languages that do not support
- IMA this option will be ignored, and the compiler will be invoked
- once for each source file in that language. If you use this
- option in conjunction with `-save-temps', the compiler will
- generate multiple pre-processed files (one for each source file),
- but only one (combined) `.o' or `.s' file.
-
-`--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' will also be 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 which
- have no documentation associated with them will also be 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'
- This will display all of the optimization options supported
- by the compiler.
-
- `warnings'
- This will display all of the options controlling warning
- messages produced by the compiler.
-
- `target'
- This will display target-specific options. Unlike the
- `--target-help' option however, target-specific options of the
- linker and assembler will not be displayed. This is because
- those tools do not currently support the extended `--help='
- syntax.
-
- `params'
- This will display the values recognized by the `--param'
- option.
-
- LANGUAGE
- This will display the options supported for LANGUAGE, where
- LANGUAGE is the name of one of the languages supported in this
- version of GCC.
-
- `common'
- This will display the options that are common to all
- languages.
-
- These are the supported qualifiers:
-
- `undocumented'
- Display only those options which are undocumented.
-
- `joined'
- Display options which take an argument that appears after an
- equal sign in the same continuous piece of text, such as:
- `--help=target'.
-
- `separate'
- Display options which take 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 the following can be used:
-
- --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), which have a description the following can be used:
-
- --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 by so much that there is nothing to display.
- One case where it does work however is when one of the classes is
- TARGET. So for example to display all the target-specific
- optimization options the following can be used:
-
- --help=target,optimizers
-
- The `--help=' option can be repeated on the command line. Each
- successive use will display 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
-
-`--version'
- Display the version number and copyrights of the invoked GCC.
-
-`-wrapper'
- Invoke all subcommands under a wrapper program. It takes a single
- comma separated list as an argument, which will be used to invoke
- the wrapper:
-
- gcc -c t.c -wrapper gdb,--args
-
- This will invoke all subprograms of gcc under "gdb -args", thus
- cc1 invocation will be "gdb -args cc1 ...".
-
-`@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.
-
-\1f
-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 treats `.c', `.h' and `.i' files as C++
-source files instead of C source files unless `-x' is used, and
-automatically specifies linking against the C++ library. 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.
-
-\1f
-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=c89'. 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, `-pedantic' 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 would normally be 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 `c89' or
- `c++98', and GNU dialects of those standards, such as `gnu89' or
- `gnu++98'. By specifying a base standard, the compiler will
- accept all programs following that standard and those using GNU
- extensions that do not contradict it. For example, `-std=c89'
- 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, by
- specifying a GNU dialect of a standard, all features the compiler
- support are enabled, even when those features change the meaning
- of the base standard and some strict-conforming programs may be
- rejected. The particular standard is used by `-pedantic' to
- identify which features are GNU extensions given that version of
- the standard. For example `-std=gnu89 -pedantic' would warn about
- C++ style `//' comments, while `-std=gnu99 -pedantic' would not.
-
- A value for this option must be provided; possible values are
-
- `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. Note that this standard is not yet fully supported;
- see `http://gcc.gnu.org/gcc-4.4/c99status.html' for more
- information. The names `c9x' and `iso9899:199x' are
- deprecated.
-
- `gnu89'
- GNU dialect of ISO C90 (including some C99 features). This is
- the default for C code.
-
- `gnu99'
- `gnu9x'
- GNU dialect of ISO C99. When ISO C99 is fully implemented in
- GCC, this will become the default. The name `gnu9x' is
- deprecated.
-
- `c++98'
- The 1998 ISO C++ standard plus amendments. Same as `-ansi' for
- C++ code.
-
- `gnu++98'
- GNU dialect of `-std=c++98'. This is the default for C++
- code.
-
- `c++0x'
- The working draft of the upcoming ISO C++0x standard. This
- option enables experimental features that are likely to be
- included in C++0x. The working draft is constantly changing,
- and any feature that is enabled by this flag may be removed
- from future versions of GCC if it is not part of the C++0x
- standard.
-
- `gnu++0x'
- GNU dialect of `-std=c++0x'. This option enables experimental
- features that may be removed in future versions of GCC.
-
-`-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 C89 or gnu89 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 Common Predefined Macros:
- (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.
-
-`-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 that 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 takes place in 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 takes place in 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 v2.5 `http://www.openmp.org/'. This option
- implies `-pthread', and thus is only supported on targets that
- have support for `-pthread'.
-
-`-fms-extensions'
- Accept some non-standard constructs used in Microsoft header files.
-
- 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.
-
-`-trigraphs'
- Support ISO C trigraphs. The `-ansi' option (and `-std' options
- for strict ISO C conformance) implies `-trigraphs'.
-
-`-no-integrated-cpp'
- Performs a compilation in two passes: preprocessing and compiling.
- This option allows a user supplied "cc1", "cc1plus", or "cc1obj"
- via the `-B' option. The user supplied compilation step can then
- add in an additional preprocessing step after normal preprocessing
- but before compiling. The default is to use the integrated cpp
- (internal cpp)
-
- The semantics of this option will change if "cc1", "cc1plus", and
- "cc1obj" are merged.
-
-`-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.
-
-\1f
-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; but 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. Version 2 is the version of the C++
- ABI that first appeared in G++ 3.4. Version 1 is the version of
- the C++ ABI that first appeared in G++ 3.2. Version 0 will always
- be the version that conforms most closely to the C++ ABI
- specification. Therefore, the ABI obtained using version 0 will
- change as ABI bugs are fixed.
-
- The default is version 2.
-
-`-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' will only return `0' if it is declared `throw()',
- in which case the compiler will always check 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)'.
-
-`-fconserve-space'
- Put uninitialized or runtime-initialized global variables into the
- common segment, as C does. This saves space in the executable at
- the cost of not diagnosing duplicate definitions. If you compile
- with this flag and your program mysteriously crashes after
- `main()' has completed, you may have an object that is being
- destroyed twice because two definitions were merged.
-
- This option is no longer useful on most targets, now that support
- has been added for putting variables into BSS without making them
- common.
-
-`-fno-deduce-init-list'
- Disable 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 option is present because this deduction is an extension to
- the current specification in the C++0x working draft, and there was
- some concern about potential overload resolution problems.
-
-`-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
- which 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 which 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 runtime. 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 will still optimize based on the
- specifications, so throwing an unexpected exception will result in
- undefined behavior.
-
-`-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++.
-
- The default if neither flag is given 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 which 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 will 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 will cause linker
- errors if these functions are not inlined everywhere they are
- called.
-
-`-fms-extensions'
- Disable pedantic 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.
-
-`-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' will allow some
- nonconforming code to compile.
-
-`-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++ runtime 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 it will
- generate it as needed. The `dynamic_cast' operator can still be
- used for casts that do not require runtime 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.
-
-`-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.
-
-`-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 will only work if your C library supports
- `__cxa_atexit'.
-
-`-fno-use-cxa-get-exception-ptr'
- Don't use the `__cxa_get_exception_ptr' runtime routine. This
- will cause `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 methods where the addresses of the two functions
- were 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 will have 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 which are defined in more than one
- different shared object: those declarations are permitted if
- they would have been permitted when this option was not used.
-
- In new code it is better to use `-fvisibility=hidden' and export
- those classes which 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 will be different, so changing one will
- 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.
-
-`-fno-weak'
- Do not use weak symbol support, even if it is provided by the
- linker. By default, G++ will use weak symbols if they are
- available. This option exists only for testing, and should not be
- used by end-users; it will result 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:
-
-`-fno-default-inline'
- Do not assume `inline' for functions defined inside a class scope.
- *Note Options That Control Optimization: Optimize Options. Note
- that these functions will have linkage like inline functions; they
- just won't be inlined by default.
-
-`-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 will be 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 at this point 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++ will place `B::f2' into the same byte
- as`A::f1'; other compilers will 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 will cause
- G++ and other compilers to layout `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++ will not place `B' into the tail-padding for
- `A'; other compilers will. You can avoid this problem by
- explicitly padding `A' so that its size is a multiple of its
- alignment (ignoring virtual base classes); that will cause
- G++ and other compilers to layout `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++ will make
- 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++ will place 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 psABI related changes. The known psABI changes at
- this point include:
-
- * For SYSV/x86-64, when passing union with long double, it is
- changed to pass in memory as specified in psABI. For example:
-
- union U {
- long double ld;
- int i;
- };
-
- `union U' will always be 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.
-
-`-Wnon-virtual-dtor (C++ and Objective-C++ only)'
- Warn when a class has virtual functions and accessible non-virtual
- destructor, in which case it would be possible but unsafe to delete
- an instance of a derived class through a pointer to the base class.
- This warning is also 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 will rearrange 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'.
-
- 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++' book:
-
- * Item 11: Define a copy constructor and an assignment
- operator for classes with dynamically allocated memory.
-
- * Item 12: Prefer initialization to assignment in constructors.
-
- * Item 14: Make destructors virtual in base classes.
-
- * Item 15: Have `operator=' return a reference to `*this'.
-
- * Item 23: Don't try to return a reference when you must
- return an object.
-
-
- Also warn about violations of the following style guidelines from
- Scott Meyers' `More Effective C++' book:
-
- * Item 6: Distinguish between prefix and postfix forms of
- increment and decrement operators.
-
- * Item 7: Never overload `&&', `||', or `,'.
-
-
- 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 also 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 not 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();
-
- will fail 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++ would try to
- preserve unsignedness, but the standard mandates the current
- behavior.
-
- struct A {
- operator int ();
- A& operator = (int);
- };
-
- main ()
- {
- A a,b;
- a = b;
- }
-
- In this example, G++ will synthesize a default `A& operator =
- (const A&);', while cfront will use the user-defined `operator ='.
-
-\1f
-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. See *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, but 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, will
- override 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 (e.g., `[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. Currently, this option is only available in
- conjunction with the NeXT runtime on Mac OS X 10.3 and later.
-
-`-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 that
- will run 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 that will run all such default destructors,
- in reverse order.
-
- The `- (id) .cxx_construct' and/or `- (void) .cxx_destruct' methods
- thusly generated will 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 will be invoked by the runtime
- immediately after a new object instance is allocated; the `-
- (void) .cxx_destruct' methods will be 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 unavailable in conjunction with the NeXT runtime on Mac
- OS X 10.2 and earlier.
-
- @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:
-
- * 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').
-
- The `-fobjc-exceptions' switch also enables the use of
- synchronization blocks for thread-safe execution:
-
- @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.
-
-`-fobjc-gc'
- Enable garbage collection (GC) in Objective-C and Objective-C++
- programs.
-
-`-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.
-
-`-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 will omit such warnings if any differences found are
- confined to types which 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.
-
-
-\1f
-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, ...). The options described
-below can be used to control the diagnostic messages formatting
-algorithm, e.g. how many characters per line, how often source location
-information should be reported. Right now, only the C++ front end can
-honor these options. However it is expected, in the near future, that
-the remaining front ends would be able to digest them correctly.
-
-`-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 will be done; each error message will appear on a
- single line.
-
-`-fdiagnostics-show-location=once'
- Only meaningful in line-wrapping mode. Instructs the diagnostic
- messages reporter to emit _once_ source location information; 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-show-option'
- This option instructs the diagnostic machinery to add text to each
- diagnostic emitted, which indicates which command line option
- directly controls that diagnostic, when such an option is known to
- the diagnostic machinery.
-
-`-Wcoverage-mismatch'
- Warn if feedback profiles do not match when using the
- `-fprofile-use' option. If a source file was changed between
- `-fprofile-gen' and `-fprofile-use', the files with the profile
- feedback can fail to match the source file and GCC can not use the
- profile feedback information. By default, GCC emits an error
- message in this case. The option `-Wcoverage-mismatch' emits a
- warning instead of an error. GCC does not use appropriate
- feedback profiles, so using this option can result in poorly
- optimized code. This option is useful only in the case of very
- minor changes such as bug fixes to an existing code-base.
-
-
-\1f
-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 which are
-not inherently erroneous but which 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.
-
-`-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. You can
- use the `-fdiagnostics-show-option' option to have each
- controllable warning amended with the option which controls it, to
- determine what to use with this option.
-
- 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 `-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::.
-
-`-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 will 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.
-
- `-pedantic' 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 `-pedantic' 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 `-pedantic'. 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 `gnu89' or `gnu99', there is a corresponding
- "base standard", the version of ISO C on which the GNU extended
- dialect is based. Warnings from `-pedantic' are given where they
- are required by the base standard. (It would 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 `-pedantic', 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++0x-compat
- -Wchar-subscripts
- -Wimplicit-int
- -Wimplicit-function-declaration
- -Wcomment
- -Wformat
- -Wmain (only for C/ObjC and unless `-ffreestanding')
- -Wmissing-braces
- -Wnonnull
- -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')
-
- 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 which has been declared
- `register'.
-
- * (C++ only) Taking the address of a variable which has been
- declared `register'.
-
- * (C++ only) A base class is not initialized in a derived
- class' 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'.
-
-`-Wformat'
- 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 `-pedantic' is used with `-Wformat', warnings will be
- 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.
-
- Since `-Wformat' also checks for null format arguments for several
- functions, `-Wformat' also implies `-Wnonnull'.
-
- `-Wformat' is included in `-Wall'. For more control over some
- aspects of format checking, the options `-Wformat-y2k',
- `-Wno-format-extra-args', `-Wno-format-zero-length',
- `-Wformat-nonliteral', `-Wformat-security', and `-Wformat=2' are
- available, but are not included in `-Wall'.
-
-`-Wformat-y2k'
- If `-Wformat' is specified, also warn about `strftime' formats
- which may yield only a two-digit year.
-
-`-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 will suppress
- 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 (C and Objective-C only)'
- If `-Wformat' is specified, do not warn about zero-length formats.
- The C standard specifies that zero-length formats are allowed.
-
-`-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=2'
- Enable `-Wformat' plus format checks not included in `-Wformat'.
- Currently equivalent to `-Wformat -Wformat-nonliteral
- -Wformat-security -Wformat-y2k'.
-
-`-Wnonnull (C and Objective-C only)'
- 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 which are initialized with
- themselves. Note this option can only be used with the
- `-Wuninitialized' option.
-
- For example, GCC will warn about `i' being uninitialized in the
- following snippet only when `-Winit-self' has been specified:
- int f()
- {
- int i = i;
- return i;
- }
-
-`-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'
- 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 `-pedantic'.
-
-`-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.
-
- 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 will issue 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'
- could belong to the enclosing `if'. The resulting code would look
- like this:
-
- {
- if (a)
- {
- if (b)
- foo ();
- else
- bar ();
- }
- }
-
- 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 defines 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++.
-
-`-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 a 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. 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.
-
-`-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-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-parameter'
- Warn whenever a function parameter is unused aside from its
- declaration.
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
-`-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]' will cause a warning, while
- `x[(void)i,j]' will 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 which 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 which 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 will depend 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.
-
- These warnings are made optional because GCC is not smart enough
- to see all the reasons why the code might be correct despite
- 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. Here is another common
- case:
-
- {
- int save_y;
- if (change_y) save_y = y, y = new_y;
- ...
- if (change_y) y = save_y;
- }
-
- This has no bug because `save_y' is used only if it is set.
-
- 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 which 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 which is not
- understood by GCC. If this command line option is used, warnings
- will even be issued for unknown pragmas in system header files.
- This is not the case if the warnings were 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 which 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 which 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=n', with
- n=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 frontend 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 frontend 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 punn+dereference pattern in the frontend:
- `*(int*)&some_float'. If optimization is enabled, it also runs in
- the backend, 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 which 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 which 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 will require, in particular when determining whether a loop
- will be executed at all.
-
- `-Wstrict-overflow=1'
- Warn about cases which are both questionable and easy to
- avoid. For example: `x + 1 > x'; with `-fstrict-overflow',
- the compiler will simplify this 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' will be simplified to `x > 0'.
-
- `-Wstrict-overflow=4'
- Also warn about other simplifications not covered by the
- above cases. For example: `(x * 10) / 5' will be 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' will be 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 will give a very large number of false
- positives.
-
-`-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 will _not_ warn about
- unknown pragmas in system headers--for that, `-Wunknown-pragmas'
- must also be used.
-
-`-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 would 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 which
- 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 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 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 would cause 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 will 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 shadows another local variable,
- parameter or global variable or whenever a built-in function is
- shadowed.
-
-`-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.
-
-`-Wunsafe-loop-optimizations'
- Warn if the loop cannot be optimized because the compiler could not
- assume anything on the bounds of the loop indices. With
- `-funsafe-loop-optimizations' warn if the compiler made such
- assumptions.
-
-`-Wno-pedantic-ms-format (MinGW targets only)'
- Disables the warnings about non-ISO `printf' / `scanf' format
- width specifiers `I32', `I64', and `I' used on Windows targets
- depending on the MS runtime, when you are using the options
- `-Wformat' and `-pedantic' without gnu-extensions.
-
-`-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 `-pedantic'.
-
-`-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++0x-compat (C++ and Objective-C++ only)'
- Warn about C++ constructs whose meaning differs between ISO C++
- 1998 and ISO C++ 200x, e.g., identifiers in ISO C++ 1998 that will
- become keywords in ISO C++ 200x. This warning 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 *'.
-
-`-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 will get a warning. These warnings
- will 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 will
- just be 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'.
-
-`-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 conversions between `NULL' and non-pointer
- types; confusing overload resolution for user-defined conversions;
- and conversions that will 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.
-
-`-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 (C++ and Objective-C++ only)'
- Warn about a comparison between values of different enum types.
- This warning is enabled by default.
-
-`-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'.
-
-`-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-attributes'
- Do not warn if an unexpected `__attribute__' is used, such as
- unrecognized attributes, function attributes applied to variables,
- etc. This will 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 which 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. The aim is to detect global functions that
- fail to be declared in header files.
-
-`-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
- 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 would cause 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 would 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'.
-
-`-Wmissing-noreturn'
- Warn about functions which might be candidates for attribute
- `noreturn'. Note these are only possible candidates, not absolute
- ones. Care should be taken to manually verify functions actually
- do not ever return before adding the `noreturn' attribute,
- otherwise subtle code generation bugs could be introduced. You
- will not get a warning for `main' in hosted C environments.
-
-`-Wmissing-format-attribute'
- Warn about function pointers which might be candidates for `format'
- attributes. Note these are only possible candidates, not absolute
- ones. GCC will guess 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 will also warn about function definitions which might be
- candidates for `format' attributes. Again, these are only
- possible candidates. GCC will guess 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.
-
-`-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 which have not been
- normalized; this option controls that warning.
-
- There are four levels of warning that GCC supports. The default is
- `-Wnormalized=nfc', which warns about any identifier which is not
- in the ISO 10646 "C" normalized form, "NFC". NFC is the
- recommended form for most uses.
-
- Unfortunately, there are some characters which ISO C and ISO C++
- allow in identifiers that when turned into NFC aren't allowable as
- 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 would only want to do this if you were
- 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", will display just like a regular `n' which
- 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 will warn 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
- is unable to 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.
-
-`-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' will be
- 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.
-
-`-Wunreachable-code'
- Warn if the compiler detects that code will never be executed.
-
- This option is intended to warn when the compiler detects that at
- least a whole line of source code will never be executed, because
- some condition is never satisfied or because it is after a
- procedure that never returns.
-
- It is possible for this option to produce a warning even though
- there are circumstances under which part of the affected line can
- be executed, so care should be taken when removing
- apparently-unreachable code.
-
- For instance, when a function is inlined, a warning may mean that
- the line is unreachable in only one inlined copy of the function.
-
- This option is not made part of `-Wall' because in a debugging
- version of a program there is often substantial code which checks
- correct functioning of the program and is, hopefully, unreachable
- because the program does work. Another common use of unreachable
- code is to provide behavior which is selectable at compile-time.
-
-`-Winline'
- Warn if a function can not be inlined and it was declared as
- inline. Even with this option, the compiler will 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 (C and Objective-C only)'
- Suppress warnings from casts to pointer type of an integer of a
- different size.
-
-`-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 default. To inhibit
- the warning messages, use `-Wno-long-long'. Flags `-Wlong-long'
- and `-Wno-long-long' are taken into account only when `-pedantic'
- flag is used.
-
-`-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'.
-
-`-Wvla'
- Warn if variable length array is used in the code. `-Wno-vla'
- will prevent the `-pedantic' 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 were unable to
- handle the code effectively. Often, the problem is that your code
- is too big or too complex; GCC will refuse 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 `-pedantic', 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 will not be protected against stack
- smashing.
-
-`-Wno-mudflap'
- Suppress warnings about constructs that cannot be instrumented by
- `-fmudflap'.
-
-`-Woverlength-strings'
- Warn about string constants which are longer than the "minimum
- maximum" length specified in the C standard. Modern compilers
- generally allow string constants which 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 C89, 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 `-pedantic', and can be disabled with
- `-Wno-overlength-strings'.
-
-\1f
-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 will probably make 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
- were already at hand; some statements may execute in different
- places because they were 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.
-
-`-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.
-
-`-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 which 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 will increase the size of
- debugging information by as much as a factor of two.
-
-`-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-2'
- Produce debugging information in DWARF version 2 format (if that is
- supported). This is the format used by DBX on IRIX 6. With this
- option, GCC uses features of DWARF version 3 when they are useful;
- version 3 is upward compatible with version 2, but may still cause
- problems for older debuggers.
-
-`-gvms'
- Produce debugging information in VMS debug format (if that is
- supported). This is the format used by DEBUG on 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, but no
- information about local variables and no line numbers.
-
- 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 DWARF2.
-
-`-feliminate-dwarf2-dups'
- Compress DWARF2 debugging information by eliminating duplicated
- information about each symbol. This option only makes sense when
- generating DWARF2 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 was 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 was 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 will generate
- 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 will serve 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 would be legal, 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 will 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 types declared in `foo.c' and `foo.h'
- will have debug information, but types declared in other header
- will not. 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 which 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.
-
-`-fpre-ipa-mem-report'
-
-`-fpost-ipa-mem-report'
- Makes the compiler print some statistics about permanent memory
- allocation before or after interprocedural optimization.
-
-`-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 will match the source files more closely, if you do
- not optimize.
-
-`-fdbg-cnt-list'
- Print the name and the counter upperbound for all debug counters.
-
-`-fdbg-cnt=COUNTER-VALUE-LIST'
- Set the internal debug counter upperbound. COUNTER-VALUE-LIST is a
- comma-separated list of NAME:VALUE pairs which sets the upperbound
- of each debug counter NAME to VALUE. All debug counters have the
- initial upperbound of UINT_MAX, thus dbg_cnt() returns true always
- unless the upperbound is set by this option. e.g. With
- -fdbg-cnt=dce:10,tail_call:0 dbg_cnt(dce) will return true only
- for first 10 invocations and dbg_cnt(tail_call) will return false
- always.
-
-`-dLETTERS'
-`-fdump-rtl-PASS'
- 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. 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 sub-expression 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 pro and epilogues.
-
- `-fdump-rtl-regmove'
- Dump after the register move pass.
-
- `-fdump-rtl-sched1'
- `-fdump-rtl-sched2'
- `-fdump-rtl-sched1' and `-fdump-rtl-sched2' enable dumping
- after the basic block scheduling passes.
-
- `-fdump-rtl-see'
- Dump after sign 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.
-
- `-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.
-
- `-dm'
- Print statistics on memory usage, at the end of the run, to
- standard error.
-
- `-dp'
- Annotate the assembler output with a comment indicating which
- pattern and alternative was 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.
-
- `-dv'
- For each of the other indicated dump files
- (`-fdump-rtl-PASS'), dump a representation of the control
- flow graph suitable for viewing with VCG to `FILE.PASS.vcg'.
-
- `-dx'
- Just generate RTL for a function instead of compiling it.
- Usually used with `-fdump-rtl-expand'.
-
- `-dy'
- Dump debugging information during parsing, to standard error.
-
-`-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-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. 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. 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. 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-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. If the `-OPTION' form is
- used, `-stats' will cause counters to be summed over the whole
- compilation unit while `-details' will dump 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'
- 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. If
- the `-OPTIONS' form is used, OPTIONS is a list of `-' separated
- options that control the details of the dump. Not all options are
- applicable to all dumps, those which are not meaningful will be
- 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.
-
- `slim'
- 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.
-
- `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).
-
- `stats'
- Enable dumping various statistics about the pass (not honored
- by every dump option).
-
- `blocks'
- Enable showing basic block boundaries (disabled in raw dumps).
-
- `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.
-
- `all'
- Turn on all options, except `raw', `slim', `verbose' and
- `lineno'.
-
- 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.
-
- `vcg'
- Dump the control flow graph of each function to a file in VCG
- format. The file name is made by appending `.vcg' to the
- source file name. Note that if the file contains more than
- one function, the generated file cannot be used directly by
- VCG. You will need to cut and paste each function's graph
- into its own separate file first.
-
- `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.
-
- `mudflap'
- Dump each function after adding mudflap instrumentation. The
- file name is made by appending `.mudflap' 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.
-
- `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.
-
-`-ftree-vectorizer-verbose=N'
- This option controls the amount of debugging output the vectorizer
- prints. This information is written to standard error, unless
- `-fdump-tree-all' or `-fdump-tree-vect' is specified, in which
- case it is output to the usual dump listing file, `.vect'. For
- N=0 no diagnostic information is reported. If N=1 the vectorizer
- reports each loop that got vectorized, and the total number of
- loops that got vectorized. If N=2 the vectorizer also reports
- non-vectorized loops that passed the first analysis phase
- (vect_analyze_loop_form) - i.e. countable, inner-most, single-bb,
- single-entry/exit loops. This is the same verbosity level that
- `-fdump-tree-vect-stats' uses. Higher verbosity levels mean
- either more information dumped for each reported loop, or same
- amount of information reported for more loops: If N=3, alignment
- related information is added to the reports. If N=4,
- data-references related information (e.g. memory dependences,
- memory access-patterns) is added to the reports. If N=5, the
- vectorizer reports also non-vectorized inner-most loops that did
- not pass the first analysis phase (i.e., may not be countable, or
- may have complicated control-flow). If N=6, the vectorizer
- reports also non-vectorized nested loops. For N=7, all the
- information the vectorizer generates during its analysis and
- transformation is reported. This is the same verbosity level that
- `-fdump-tree-vect-details' uses.
-
-`-frandom-seed=STRING'
- This option provides a seed that GCC uses when it would otherwise
- use random numbers. It is used to generate 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, `.sched' 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'
- 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' would produce
- 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'.
-
-`-time'
- 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). 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.
-
-`-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.
-
-`-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-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' will search--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 will be 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::.
-
-`-feliminate-unused-debug-types'
- Normally, when producing DWARF2 output, GCC will emit debugging
- information for all types declared in a compilation unit,
- regardless of whether or not they are actually used in that
- compilation unit. Sometimes this is useful, such as 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. With this
- option, GCC will avoid producing debug symbol output for types
- that are nowhere used in the source file being compiled.
-
-\1f
-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 would 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.
-
-`-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
- -fcprop-registers
- -fdce
- -fdefer-pop
- -fdelayed-branch
- -fdse
- -fguess-branch-probability
- -fif-conversion2
- -fif-conversion
- -finline-small-functions
- -fipa-pure-const
- -fipa-reference
- -fmerge-constants
- -fsplit-wide-types
- -ftree-builtin-call-dce
- -ftree-ccp
- -ftree-ch
- -ftree-copyrename
- -ftree-dce
- -ftree-dominator-opts
- -ftree-dse
- -ftree-fre
- -ftree-sra
- -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
- -fexpensive-optimizations
- -fgcse -fgcse-lm
- -findirect-inlining
- -foptimize-sibling-calls
- -fpeephole2
- -fregmove
- -freorder-blocks -freorder-functions
- -frerun-cse-after-loop
- -fsched-interblock -fsched-spec
- -fschedule-insns -fschedule-insns2
- -fstrict-aliasing -fstrict-overflow
- -ftree-switch-conversion
- -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' and `-ftree-vectorize' 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 -ftree-vect-loop-version
-
- 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' would be `-fno-foo'. In the table below, only one of the forms
-is listed--the one you typically will 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-default-inline'
- Do not make member functions inline by default merely because they
- are defined inside the class scope (C++ only). Otherwise, when
- you specify `-O', member functions defined inside class scope are
- compiled inline by default; i.e., you don't need to add `inline'
- in front of the member function name.
-
-`-fno-defer-pop'
- Always pop the arguments to each function call as soon as that
- function returns. For machines which 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 `-O2',
- `-O3', `-Os'.
-
-`-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.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-foptimize-sibling-calls'
- Optimize sibling and tail recursive calls.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fno-inline'
- Don't pay attention to the `inline' keyword. Normally this option
- is used to keep the compiler from expanding any functions inline.
- Note that if you are not optimizing, no functions can be expanded
- inline.
-
-`-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.
-
- 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'
- Integrate all simple functions into their callers. The compiler
- heuristically decides which functions are simple enough to be 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.
-
-`-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.
-
-`-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 C89. 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 the variable was 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 will
- result 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 will be deleted which will trigger 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'.
-
-`-fmudflap -fmudflapth -fmudflapir'
- For front-ends that support it (C and C++), instrument all risky
- pointer/array dereferencing operations, some standard library
- string/heap functions, and some other associated constructs with
- range/validity tests. Modules so instrumented should be immune to
- buffer overflows, invalid heap use, and some other classes of C/C++
- programming errors. The instrumentation relies on a separate
- runtime library (`libmudflap'), which will be linked into a
- program if `-fmudflap' is given at link time. Run-time behavior
- of the instrumented program is controlled by the `MUDFLAP_OPTIONS'
- environment variable. See `env MUDFLAP_OPTIONS=-help a.out' for
- its options.
-
- Use `-fmudflapth' instead of `-fmudflap' to compile and to link if
- your program is multi-threaded. Use `-fmudflapir', in addition to
- `-fmudflap' or `-fmudflapth', if instrumentation should ignore
- pointer reads. This produces less instrumentation (and therefore
- faster execution) and still provides some protection against
- outright memory corrupting writes, but allows erroneously read
- data to propagate within a program.
-
-`-fthread-jumps'
- Perform optimizations where we 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 will follow 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 which 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
- has been 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 runtime 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 will attempt to move loads which 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 gcse is enabled.
-
-`-fgcse-sm'
- When `-fgcse-sm' is enabled, a store motion pass is run after
- global common subexpression elimination. This pass will attempt
- 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
- cleanup redundant spilling.
-
-`-funsafe-loop-optimizations'
- If given, the loop optimizer will assume that loop indices do not
- overflow, and that the 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. Using `-Wunsafe-loop-optimizations', the compiler will
- warn you if it finds this kind of loop.
-
-`-fcrossjumping'
- Perform cross-jumping transformation. This transformation unifies
- equivalent code and save 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 include 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'.
-
-`-fdelete-null-pointer-checks'
- Use global dataflow analysis to identify and eliminate useless
- checks for null pointers. The compiler assumes that dereferencing
- a null pointer would have halted the program. If a pointer is
- checked after it has already been dereferenced, it cannot be null.
-
- In some environments, this assumption is not true, and programs can
- safely dereference null pointers. Use
- `-fno-delete-null-pointer-checks' to disable this optimization for
- programs which depend on that behavior.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fexpensive-optimizations'
- Perform a number of minor optimizations that are relatively
- expensive.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-foptimize-register-move'
-`-fregmove'
- Attempt to reassign register numbers in move instructions and as
- operands of other simple instructions in order to maximize the
- amount of register tying. This is especially helpful on machines
- with two-operand instructions.
-
- Note `-fregmove' and `-foptimize-register-move' are the same
- optimization.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fira-algorithm=ALGORITHM'
- Use specified coloring algorithm for the integrated register
- allocator. The ALGORITHM argument should be `priority' or `CB'.
- The first algorithm specifies Chow's priority coloring, the second
- one specifies Chaitin-Briggs coloring. The second algorithm can
- be unimplemented for some architectures. If it is implemented, it
- is the default because Chaitin-Briggs coloring as a rule generates
- a better code.
-
-`-fira-region=REGION'
- Use specified regions for the integrated register allocator. The
- REGION argument should be one of `all', `mixed', or `one'. The
- first value means using all loops as register allocation regions,
- the second value which is the default means using all loops except
- for loops with small register pressure as the regions, and third
- one means using all function as a single region. The first value
- can give best result for machines with small size and irregular
- register set, the third one results in faster and generates decent
- code and the smallest size code, and the default value usually
- give the best results in most cases and for most architectures.
-
-`-fira-coalesce'
- Do optimistic register coalescing. This option might be
- profitable for architectures with big regular register files.
-
-`-fno-ira-share-save-slots'
- Switch off sharing stack slots used for saving call used hard
- registers living through a call. Each hard register will get a
- separate stack slot and as a result function stack frame will be
- bigger.
-
-`-fno-ira-share-spill-slots'
- Switch off sharing stack slots allocated for pseudo-registers.
- Each pseudo-register which did not get a hard register will get a
- separate stack slot and as a result function stack frame will be
- bigger.
-
-`-fira-verbose=N'
- Set up how verbose dump file for the integrated register allocator
- will be. Default value is 5. If the value is greater or equal to
- 10, the dump file will be stderr as if the value were 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', `-Os'.
-
-`-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-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
- will be 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) will be examined for a
- dependency on a stalled insn that is 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, do use superblock
- scheduling algorithm. Superblock scheduling allows motion across
- basic block boundaries resulting on 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.
-
-`-fsched2-use-traces'
- Use `-fsched2-use-superblocks' algorithm when scheduling after
- register allocation and additionally perform code duplication in
- order to increase the size of superblocks using tracer pass. See
- `-ftracer' for details on trace formation.
-
- This mode should produce faster but significantly longer programs.
- Also without `-fbranch-probabilities' the traces constructed may
- not match the reality and hurt the performance. This only makes
- sense when scheduling after register allocation, i.e. with
- `-fschedule-insns2' or at `-O2' or higher.
-
-`-fsee'
- Eliminate redundant sign extension instructions and move the
- non-redundant ones to optimal placement using lazy code motion
- (LCM).
-
-`-freschedule-modulo-scheduled-loops'
- The modulo scheduling comes before the traditional scheduling, if
- a loop was modulo scheduled we may want to prevent the later
- scheduling passes from changing its schedule, we use this option
- to control that.
-
-`-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 until 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 until
- `-fsel-sched-pipelining' is turned on.
-
-`-fcaller-saves'
- Enable values to be allocated in registers that will be 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 than would otherwise
- be produced.
-
- 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'.
-
-`-fconserve-stack'
- Attempt to minimize stack usage. The compiler will attempt 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-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-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 cannot escape the
- compilation unit. Enabled by default at `-O' and higher.
-
-`-fipa-struct-reorg'
- Perform structure reorganization optimization, that change C-like
- structures layout in order to better utilize spatial locality.
- This transformation is affective for programs containing arrays of
- structures. Available in two compilation modes: profile-based
- (enabled with `-fprofile-generate') or static (which uses built-in
- heuristics). Require `-fipa-type-escape' to provide the safety of
- this transformation. It works only in whole program mode, so it
- requires `-fwhole-program' and `-combine' to be enabled.
- Structures considered `cold' by this transformation are not
- affected (see `--param struct-reorg-cold-struct-ratio=VALUE').
-
- With this flag, the program debug info reflects a new structure
- layout.
-
-`-fipa-pta'
- Perform interprocedural pointer analysis. This option is
- experimental and does not affect generated code.
-
-`-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 will perform 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'.
-
-`-fipa-matrix-reorg'
- Perform matrix flattening and transposing. Matrix flattening
- tries to replace a m-dimensional matrix with its equivalent
- n-dimensional matrix, where n < m. This reduces the level of
- indirection needed for accessing the elements of the matrix. The
- second optimization is matrix transposing that attempts to change
- the order of the matrix's dimensions in order to improve cache
- locality. Both optimizations need the `-fwhole-program' flag.
- Transposing is enabled only if profiling information is available.
-
-`-ftree-sink'
- Perform forward store motion on trees. This flag is enabled by
- default at `-O' and higher.
-
-`-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-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
- builtin 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 which will later be 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 linear loop transformations on tree. This flag can
- improve cache performance and allow further loop optimizations to
- take place.
-
-`-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 will transform the loop as if the user had
- 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. For example, given a loop like:
- DO I = 1, N
- A(I) = A(I) + C
- ENDDO
- loop strip mining will transform the loop as if the user had
- written:
- DO II = 1, N, 4
- DO I = II, min (II + 3, 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. 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 will transform the loop as if the user had written:
- DO II = 1, N, 64
- DO JJ = 1, M, 64
- DO I = II, min (II + 63, N)
- DO J = JJ, min (JJ + 63, 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 will iterate over a smaller amount of
- data that 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.
-
-`-fcheck-data-deps'
- Compare the results of several data dependence analyzers. This
- option is used for debugging the data dependence analyzers.
-
-`-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-im'
- Perform loop invariant motion on trees. This pass moves only
- invariants that would be 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 the loop
- for that 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-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-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-vectorize'
- Perform loop vectorization on trees. This flag is enabled by
- default at `-O3'.
-
-`-ftree-vect-loop-version'
- Perform loop versioning when doing loop vectorization on trees.
- When a loop appears to be vectorizable except that data alignment
- or data dependence cannot be determined at compile time then
- vectorized and non-vectorized versions of the loop are generated
- along with runtime checks for alignment or dependence to control
- which version is executed. This option is enabled by default
- except at level `-Os' where it is disabled.
-
-`-fvect-cost-model'
- Enable cost model for vectorization.
-
-`-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 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 expressing 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.
-
- Combination of `-fweb' and CSE is often sufficient to obtain the
- same effect. However in cases the loop body is more complicated
- than a single basic block, this is not reliable. It also does not
- work at all on some of the architectures due to restrictions in
- the CSE pass.
-
- This optimization is enabled by default.
-
-`-fvariable-expansion-in-unroller'
- With this option, the compiler will create multiple copies of some
- local variables when unrolling a loop which can result in superior
- code.
-
-`-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 will use 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 will be 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.
-
-`-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 in 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
- will work 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 will
- not happen. This permits various optimizations. For example, the
- compiler will assume that an expression like `i + 10 > i' will
- always be 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 will overflow 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' would align 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 will not be 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 will not be 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'. The hope is that the loop will be
- executed many times, which will make up for any execution of the
- dummy operations.
-
- `-fno-align-loops' and `-falign-loops=1' are equivalent and mean
- that loops will not be 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 will not be 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 will not be removed. This option is intended to support
- existing code which relies on a particular ordering. For new
- code, it is better to use attributes.
-
- Enabled at level `-O0'. When disabled explicitly, it also imply
- `-fno-section-anchors' that 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 will no longer stay in a
- "home register".
-
- Enabled by default with `-funroll-loops'.
-
-`-fwhole-program'
- Assume that the current compilation unit represents 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 a affect gets
- more aggressively optimized by interprocedural optimizers. While
- this option is equivalent to proper use of `static' keyword for
- programs consisting of single file, in combination with option
- `--combine' this flag can be used to compile most of smaller scale
- C programs since the functions and variables become local for the
- whole combined compilation unit, not for the single source file
- itself.
-
- This option is not supported for Fortran programs.
-
-`-fcprop-registers'
- After register allocation and post-register allocation instruction
- splitting, we 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 will use heuristics to correct or
- smooth out such inconsistencies. By default, GCC will emit an
- error message when an inconsistent profile is detected.
-
-`-fprofile-dir=PATH'
- Set the directory to search 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. By default, GCC will use the current directory as PATH
- thus the profile data file will appear 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 will look 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'
-
- 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 will look 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.
-
-`-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 since it can
- result in incorrect output for programs which 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 which 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 which 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 a code
- which 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'.
-
- 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 which 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 which 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'.
-
-`-frtl-abstract-sequences'
- It is a size optimization method. This option is to find identical
- sequences of code, which can be turned into pseudo-procedures and
- then replace all occurrences with calls to the newly created
- subroutine. It is kind of an opposite of `-finline-functions'.
- This optimization runs at RTL level.
-
-`-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 constant as single precision constant instead
- of implicitly converting it to double precision constant.
-
-`-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 the 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 mostly 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 and adds `REG_VALUE_PROFILE'
- notes to instructions for their later usage in optimizations.
-
- Enabled with `-fprofile-generate' and `-fprofile-use'.
-
-`-fvpt'
- If combined with `-fprofile-arcs', it instructs the compiler to add
- a 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 operation 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 will most benefit processors with lots of registers.
- Depending on the debug information format adopted by the target,
- however, it can make debugging impossible, since variables will no
- longer stay in a "home register".
-
- Enabled by default with `-funroll-loops'.
-
-`-ftracer'
- Perform tail duplication to enlarge superblock size. This
- transformation simplifies the control flow of the function
- allowing other optimizations to do 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 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 the loops for that 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 will create larger object and executable files and will
- also be slower. You will not be able to 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 in 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.
-
-`-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; }
-
- would usually calculate the addresses of all three variables, but
- if you compile it with `-fsection-anchors', it will access 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 will not inline
- functions that contain more that 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 given in the following table:
-
- `sra-max-structure-size'
- The maximum structure size, in bytes, at which the scalar
- replacement of aggregates (SRA) optimization will perform
- block copies. The default value, 0, implies that GCC will
- select the most appropriate size itself.
-
- `sra-field-structure-ratio'
- The threshold ratio (as a percentage) between instantiated
- fields and the complete structure size. We say that if the
- ratio of the number of bytes in instantiated fields to the
- number of bytes in the complete structure exceeds this
- parameter, then block copies are not used. The default is 75.
-
- `struct-reorg-cold-struct-ratio'
- The threshold ratio (as a percentage) between a structure
- frequency and the frequency of the hottest structure in the
- program. This parameter is used by struct-reorg optimization
- enabled by `-fipa-struct-reorg'. We say that if the ratio of
- a structure frequency, calculated by profiling, to the
- hottest structure frequency in the program is less than this
- parameter, then structure reorganization is not applied to
- this structure. The default is 10.
-
- `predictable-branch-cost-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
- crossjumping. 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 compile time increase with probably small improvement in
- executable size.
-
- `min-crossjump-insns'
- The minimum number of instructions which must be matched at
- the end of two blocks before crossjumping will be performed
- on them. This value is ignored in the case where all
- instructions in the block being crossjumped 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 is searched, the time
- savings from filling the delay slot will be minimal so stop
- searching. Increasing values mean more aggressive
- optimization, making the compile time increase with probably
- small improvement in executable run 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 compile 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 will be
- allocated in order to perform the global common subexpression
- elimination optimization. If more memory than specified is
- required, the optimization will not be done.
-
- `max-gcse-passes'
- The maximum number of passes of GCSE to run. The default is
- 1.
-
- `max-pending-list-length'
- The maximum number of pending dependencies scheduling will
- allow 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-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 will consider for inlining. This only
- affects functions declared inline and methods implemented in
- a class declaration (C++). The default value is 450.
-
- `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 will be investigated. To those
- functions, a different (more restrictive) limit compared to
- functions declared inline can be applied. The default value
- is 90.
-
- `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 backend.
- 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 (consider unit consisting of function A that is
- inline and B that just calls A three time. 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.
- 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 maximum number of instructions out-of-line copy of
- 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
- function 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 maximum recursion depth used by the recursive
- inlining.
-
- For functions declared inline `--param
- max-inline-recursive-depth' is taken into account. For
- function 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 will recurse via given call expression. This
- parameter limits inlining only to call expression whose
- probability exceeds given threshold (in percents). The
- default value is 10.
-
- `inline-call-cost'
- Specify cost of call instruction relative to simple
- arithmetics operations (having cost of 1). Increasing this
- cost disqualifies inlining of non-leaf functions and at the
- same time increases size of leaf function that is believed to
- reduce function size by being inlined. In effect it
- increases amount of inlining for code having large
- abstraction penalty (many functions that just pass the
- arguments to other functions) and decrease inlining for code
- with low abstraction penalty. The default value is 12.
-
- `min-vect-loop-bound'
- The minimum number of iterations under which a loop will not
- get 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.
-
- `max-unrolled-insns'
- The maximum number of instructions that a loop should have if
- that loop is unrolled, and if the loop is unrolled, it
- 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 should have if that loop is
- unrolled, and if the loop is unrolled, it 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 should have if
- that loop is peeled, and if the loop is peeled, it determines
- how many times the loop code is peeled.
-
- `max-peel-times'
- The maximum number of peelings of a single loop.
-
- `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-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
- that all candidates are considered for each use in induction
- variable optimizations. Only the most relevant candidates
- are considered if there are more candidates, 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 number of candidates in the set is smaller than this value,
- we always try to remove unnecessary ivs from the set during
- its optimization when a new iv is added to the set.
-
- `scev-max-expr-size'
- Bound on size of expressions used in the scalar evolutions
- analyzer. Large 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 will be 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 runtime checks that can be performed
- when doing loop versioning for alignment in the vectorizer.
- See option ftree-vect-loop-version for more information.
-
- `vect-max-version-for-alias-checks'
- The maximum number of runtime checks that can be performed
- when doing loop versioning for alias in the vectorizer. See
- option ftree-vect-loop-version for more information.
-
- `max-iterations-to-track'
- The maximum number of iterations of a loop the brute force
- algorithm for analysis of # of iterations of the loop tries
- to evaluate.
-
- `hot-bb-count-fraction'
- Select fraction of the maximal count of repetitions of basic
- block in program given basic block needs to have to be
- considered hot.
-
- `hot-bb-frequency-fraction'
- Select fraction of the maximal 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 function contain single loop
- with known bound and other loop with unknown. We predict the
- known number of iterations correctly, while the unknown
- number of iterations average to roughly 10. This means that
- the loop without bounds would appear artificially cold
- relative to the other one.
-
- `align-threshold'
- Select fraction of the maximal frequency of executions of
- basic block in function given basic block will get aligned.
-
- `align-loop-iterations'
- A loop expected to iterate at lest the selected number of
- iterations will get 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 rather hokey argument, as most of the
- duplicates will be 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 do have 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'
- Maximum number of basic blocks on path that cse considers.
- The default is 10.
-
- `max-cse-insns'
- The maximum instructions CSE process before flushing. The
- default is 1000.
-
- `max-aliased-vops'
- Maximum number of virtual operands per function allowed to
- represent aliases before triggering the alias partitioning
- heuristic. Alias partitioning reduces compile times and
- memory consumption needed for aliasing at the expense of
- precision loss in alias information. The default value for
- this parameter is 100 for -O1, 500 for -O2 and 1000 for -O3.
-
- Notice that if a function contains more memory statements
- than the value of this parameter, it is not really possible
- to achieve this reduction. In this case, the compiler will
- use the number of memory statements as the value for
- `max-aliased-vops'.
-
- `avg-aliased-vops'
- Average number of virtual operands per statement allowed to
- represent aliases before triggering the alias partitioning
- heuristic. This works in conjunction with
- `max-aliased-vops'. If a function contains more than
- `max-aliased-vops' virtual operators, then memory symbols
- will be grouped into memory partitions until either the total
- number of virtual operators is below `max-aliased-vops' or
- the average number of virtual operators per memory statement
- is below `avg-aliased-vops'. The default value for this
- parameter is 1 for -O1 and -O2, and 3 for -O3.
-
- `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
- which 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 compile 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 compile time increase with probably
- slightly better performance. The default value is 500.
-
- `reorder-blocks-duplicate'
- `reorder-blocks-duplicate-feedback'
- Used by 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 and 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. 0 - disable region extension, N - do at most N
- iterations. The default value is 0.
-
- `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 insn will be scheduled. The default
- value is 40.
-
- `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 will be
- 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.
-
- `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.
-
- `min-virtual-mappings'
- Specifies the minimum number of virtual mappings in the
- incremental SSA updater that should be registered to trigger
- the virtual mappings heuristic defined by
- virtual-mappings-ratio. The default value is 100.
-
- `virtual-mappings-ratio'
- If the number of virtual mappings is virtual-mappings-ratio
- bigger than the number of virtual symbols to be updated, then
- the incremental SSA updater switches to a full update for
- those symbols. The default ratio is 3.
-
- `ssp-buffer-size'
- The minimum size of buffers (i.e. arrays) that will receive
- stack smashing protection when `-fstack-protection' is used.
-
- `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 we will treat 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 we prefetch 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.
-
- `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 will refuse 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 will allow 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 will not be done and optimizations
- depending on it will be disabled. The default maximum SCC
- size is 10000.
-
- `ira-max-loops-num'
- IRA uses a regional register allocation by default. If a
- function contains loops more than number given by the
- parameter, only at most given number of the most frequently
- executed loops will form regions for the regional register
- allocation. The default value of the parameter is 100.
-
- `ira-max-conflict-table-size'
- Although IRA uses a sophisticated algorithm of compression
- conflict table, the table can be still big for huge
- functions. If the conflict table for a function could be
- more than size in MB given by the parameter, the conflict
- table is not built and faster, simpler, and lower quality
- register allocation algorithm will be used. The algorithm do
- not use pseudo-register conflicts. The default value of the
- parameter is 2000.
-
- `loop-invariant-max-bbs-in-loop'
- Loop invariant motion can be very expensive, both in compile
- 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.
-
-
-\1f
-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 which GCC does not
- know how to 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.
-
-`-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:
- `iso9899:1990'
- `c89'
- The ISO C standard from 1990. `c89' is the customary
- shorthand for this version of the standard.
-
- The `-ansi' option is equivalent to `-std=c89'.
-
- `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.
-
- `gnu89'
- The 1990 C standard plus GNU extensions. This is the default.
-
- `gnu99'
- `gnu9x'
- The 1999 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. 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++.
-
-`-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.
-
-`-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
- Debugging Options: (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.
-
-\1f
-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 which GCC does not know
- how to 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.
-
-
-\1f
-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 will be passed to the linker. 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 will
- be passed to the linker. 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
- that 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. (For example, `__main', used to ensure C++
- constructors will be called; *note `collect2': (gccint)Collect2.)
-
-`-pie'
- Produce a position independent executable on targets which support
- it. For predictable results, you must also specify the same set
- of options that were used to generate code (`-fpie', `-fPIE', or
- model suboptions) when you specify this 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 that were used to generate code (`-fpic', `-fPIC',
- or model suboptions) when you specify this 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 will not always be 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 will link the shared version of `libgcc' into
- shared libraries by default. Otherwise, it will take advantage of
- the linker and optimize 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'.
-
-`-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 which GCC does not know how
- to 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.
-
-\1f
-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 will
- be ignored. The directory will still be 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.
-
-`-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' was
- not specified, the driver tries two standard prefixes, which are
- `/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 will check to see if the path provided by the `-B'
- refers to a directory, and if necessary it will add 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
- includes 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 run-time 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
- will be 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 that 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 would normally search for headers in
- `/usr/include' and libraries in `/usr/lib', it will instead search
- `DIR/usr/include' and `DIR/usr/lib'.
-
- If you use both this option and the `-isysroot' option, then the
- `--sysroot' option will apply to libraries, but the `-isysroot'
- option will apply 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' will still work, but
- the library aspect will not.
-
-`-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 which was current when the compiler was
- 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.
-
-\1f
-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 and it 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 will be
- deleted. (Or, if the spec did not exist, then nothing will
- happened.) Otherwise, if the spec does not currently exist a new
- spec will be created. If the spec does exist then its contents
- will be overridden by the text of this directive, unless the first
- character of that text is the `+' character, in which case the
- text will be 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 will 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 that
- follows 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 will add 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 will be 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 even if
- `%uSUFFIX' was already seen.
-
-`%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' would involve 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 off; 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' will substitute later.
-
-`%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 will be 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 would
- 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.
-
-`%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.
-
-`%[NAME]'
- Like `%(...)' but put `__' around `-D' arguments.
-
-`%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 will make 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 will be prepended to each of these
- paths.
-
-`%L'
- Process the `lib' spec. This is a spec string for deciding which
- libraries should be included on the command line to the linker.
-
-`%G'
- Process the `libgcc' spec. This is a spec string for deciding
- which GCC support library should be included on the command line
- to the linker.
-
-`%S'
- Process the `startfile' spec. This is a spec for deciding which
- object files should be 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 will be 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 will see `-S', `%' commands in the spec string
- after this one will 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)}
-
- ``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 was given to GCC. If
- that switch was 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}' would match the command-line option `-foo'
- and would output 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 names starts with `o'. %{o*} would
- substitute this text, including the space. Thus two arguments
- would be 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 was given to GCC.
-
-`%{!`S':`X'}'
- Substitutes `X', if the `-S' switch was _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' will be substituted once for
- each matching switch, with the `%*' replaced by the part of that
- switch that matched the `*'.
-
-`%{.`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' was 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}
-
- will output 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' was given to GCC, substitutes `X'; else if `T' was 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.
-
-\1f
-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. Sometimes
-this is inconvenient, so GCC provides options that will switch to
-another cross-compiler or version.
-
-`-b MACHINE'
- The argument MACHINE specifies the target machine for compilation.
-
- The value to use for MACHINE is the same as was specified as the
- machine type when configuring GCC as a cross-compiler. For
- example, if a cross-compiler was configured with `configure
- arm-elf', meaning to compile for an arm processor with elf
- binaries, then you would specify `-b arm-elf' to run that cross
- compiler. Because there are other options beginning with `-b', the
- configuration must contain a hyphen, or `-b' alone should be one
- argument followed by the configuration in the next argument.
-
-`-V VERSION'
- The argument VERSION specifies which version of GCC to run. This
- is useful when multiple versions are installed. For example,
- VERSION might be `4.0', meaning to run GCC version 4.0.
-
- The `-V' and `-b' options work by running the
-`<machine>-gcc-<version>' executable, so there's no real reason to use
-them if you can just run that directly.
-
-\1f
-File: gcc.info, Node: Submodel Options, Next: Code Gen Options, Prev: Target Options, Up: Invoking GCC
-
-3.17 Hardware Models and Configurations
-=======================================
-
-Earlier we discussed the standard option `-b' which chooses among
-different installed compilers for completely different target machines,
-such as VAX vs. 68000 vs. 80386.
-
- In addition, each of these 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:
-
-* ARC Options::
-* ARM Options::
-* AVR Options::
-* Blackfin Options::
-* CRIS Options::
-* CRX Options::
-* Darwin Options::
-* DEC Alpha Options::
-* DEC Alpha/VMS 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::
-* M32C Options::
-* M32R/D Options::
-* M680x0 Options::
-* M68hc1x Options::
-* MCore Options::
-* MIPS Options::
-* MMIX Options::
-* MN10300 Options::
-* PDP-11 Options::
-* picoChip Options::
-* PowerPC Options::
-* RS/6000 and PowerPC Options::
-* S/390 and zSeries Options::
-* Score Options::
-* SH Options::
-* SPARC Options::
-* SPU Options::
-* System V Options::
-* V850 Options::
-* VAX Options::
-* VxWorks Options::
-* x86-64 Options::
-* Xstormy16 Options::
-* Xtensa Options::
-* zSeries Options::
-
-\1f
-File: gcc.info, Node: ARC Options, Next: ARM Options, Up: Submodel Options
-
-3.17.1 ARC Options
-------------------
-
-These options are defined for ARC implementations:
-
-`-EL'
- Compile code for little endian mode. This is the default.
-
-`-EB'
- Compile code for big endian mode.
-
-`-mmangle-cpu'
- Prepend the name of the cpu to all public symbol names. In
- multiple-processor systems, there are many ARC variants with
- different instruction and register set characteristics. This flag
- prevents code compiled for one cpu to be linked with code compiled
- for another. No facility exists for handling variants that are
- "almost identical". This is an all or nothing option.
-
-`-mcpu=CPU'
- Compile code for ARC variant CPU. Which variants are supported
- depend on the configuration. All variants support `-mcpu=base',
- this is the default.
-
-`-mtext=TEXT-SECTION'
-`-mdata=DATA-SECTION'
-`-mrodata=READONLY-DATA-SECTION'
- Put functions, data, and readonly data in TEXT-SECTION,
- DATA-SECTION, and READONLY-DATA-SECTION respectively by default.
- This can be overridden with the `section' attribute. *Note
- Variable Attributes::.
-
-`-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.
-
-
-\1f
-File: gcc.info, Node: ARM Options, Next: AVR Options, Prev: ARC Options, Up: Submodel Options
-
-3.17.2 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 will cause 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 which supports calling between the ARM and Thumb
- instruction sets. Without this option 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.
-
-`-mno-sched-prolog'
- Prevent the reordering of instructions in the function prolog, or
- the merging of those instruction with the instructions in the
- function's body. This means that all functions will 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 if 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.
-
- Using `-mfloat-abi=hard' with VFP coprocessors is not supported.
- Use `-mfloat-abi=softfp' with the appropriate `-mfpu' option to
- allow the compiler to generate code that makes use of the hardware
- floating-point capabilities for these CPUs.
-
- 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.
-
-`-mhard-float'
- Equivalent to `-mfloat-abi=hard'.
-
-`-msoft-float'
- Equivalent to `-mfloat-abi=soft'.
-
-`-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.
-
-`-mcpu=NAME'
- This specifies the name of the target ARM processor. GCC uses
- this name to determine what kind of instructions it can emit when
- generating assembly code. 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',
- `arm1176jz-s', `arm1176jzf-s', `cortex-a8', `cortex-a9',
- `cortex-r4', `cortex-r4f', `cortex-m3', `cortex-m1', `xscale',
- `iwmmxt', `iwmmxt2', `ep9312'.
-
-`-mtune=NAME'
- This option is very similar to the `-mcpu=' option, except that
- instead of specifying the actual target processor type, and hence
- restricting which instructions can be used, it specifies that GCC
- should tune the performance of the code as if the target were of
- the type specified in this option, but still choosing the
- instructions that it will generate based on the cpu specified by a
- `-mcpu=' option. For some ARM implementations better performance
- can be obtained by using this option.
-
-`-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', `iwmmxt', `iwmmxt2', `ep9312'.
-
-`-mfpu=NAME'
-`-mfpe=NUMBER'
-`-mfp=NUMBER'
- This specifies what floating point hardware (or hardware
- emulation) is available on the target. Permissible names are:
- `fpa', `fpe2', `fpe3', `maverick', `vfp', `vfpv3', `vfpv3-d16' and
- `neon'. `-mfp' and `-mfpe' are synonyms for `-mfpu'=`fpe'NUMBER,
- for compatibility with older versions of GCC.
-
- If `-msoft-float' is specified this specifies the format of
- floating point values.
-
-`-mstructure-size-boundary=N'
- The size of all structures and unions will be 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 the 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 will be 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 will lie 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 will be
- turned into long calls. The heuristic is that static functions,
- functions which 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, will not be turned into long calls. The
- exception to this rule is 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, will always be turned into long calls.
-
- This feature is not enabled by default. Specifying
- `-mno-long-calls' will restore the default behavior, as will
- 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 run-time
- 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. The default
- is R10 unless stack-checking is enabled, when R9 is used.
-
-`-mcirrus-fix-invalid-insns'
- Insert NOPs into the instruction stream to in order to work around
- problems with invalid Maverick instruction combinations. This
- option is only valid if the `-mcpu=ep9312' option has been used to
- enable generation of instructions for the Cirrus Maverick floating
- point co-processor. This option is not enabled by default, since
- the problem is only present in older Maverick implementations.
- The default can be re-enabled by use of the
- `-mno-cirrus-fix-invalid-insns' switch.
-
-`-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'
- Generate code for the Thumb instruction set. The default is to
- use the 32-bit ARM instruction set. This option automatically
- enables either 16-bit Thumb-1 or mixed 16/32-bit Thumb-2
- instructions based on the `-mcpu=NAME' and `-march=NAME' options.
-
-`-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.
-
-`-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.
-
-`-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'.
-
-`-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.
-
-
-\1f
-File: gcc.info, Node: AVR Options, Next: Blackfin Options, Prev: ARM Options, Up: Submodel Options
-
-3.17.3 AVR Options
-------------------
-
-These options are defined for AVR implementations:
-
-`-mmcu=MCU'
- Specify ATMEL AVR instruction set or MCU type.
-
- Instruction set avr1 is for the minimal AVR core, not supported by
- the C compiler, only for assembler programs (MCU types: at90s1200,
- attiny10, attiny11, attiny12, attiny15, attiny28).
-
- Instruction set avr2 (default) is for the classic AVR core with up
- to 8K program memory space (MCU types: at90s2313, at90s2323,
- attiny22, at90s2333, at90s2343, at90s4414, at90s4433, at90s4434,
- at90s8515, at90c8534, at90s8535).
-
- Instruction set avr3 is for the classic AVR core with up to 128K
- program memory space (MCU types: atmega103, atmega603, at43usb320,
- at76c711).
-
- Instruction set avr4 is for the enhanced AVR core with up to 8K
- program memory space (MCU types: atmega8, atmega83, atmega85).
-
- Instruction set avr5 is for the enhanced AVR core with up to 128K
- program memory space (MCU types: atmega16, atmega161, atmega163,
- atmega32, atmega323, atmega64, atmega128, at43usb355, at94k).
-
-`-msize'
- Output instruction sizes to the asm file.
-
-`-mno-interrupts'
- Generated code is not compatible with hardware interrupts. Code
- size will be smaller.
-
-`-mcall-prologues'
- Functions prologues/epilogues expanded as call to appropriate
- subroutines. Code size will be smaller.
-
-`-mno-tablejump'
- Do not generate tablejump insns which sometimes increase code size.
- The option is now deprecated in favor of the equivalent
- `-fno-jump-tables'
-
-`-mtiny-stack'
- Change only the low 8 bits of the stack pointer.
-
-`-mint8'
- Assume int to be 8 bit integer. This affects the sizes of all
- types: A char will be 1 byte, an int will be 1 byte, an long will
- be 2 bytes and long long will be 4 bytes. Please note that this
- option does not comply to the C standards, but it will provide you
- with smaller code size.
-
-\1f
-File: gcc.info, Node: Blackfin Options, Next: CRIS Options, Prev: AVR Options, Up: Submodel Options
-
-3.17.4 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', `bf561'. The optional
- SIREVISION specifies the silicon revision of the target Blackfin
- processor. Any workarounds available for the targeted silicon
- revision will be enabled. If SIREVISION is `none', no workarounds
- are enabled. If SIREVISION is `any', all workarounds for the
- targeted processor will be 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.
-
- Support for `bf561' is incomplete. For `bf561', Only the
- processor macro is defined. Without this option, `bf532' is used
- as the processor by default. The corresponding predefined
- processor macros for CPU is to be defined. And for `bfin-elf'
- toolchain, this causes the hardware BSP provided by libgloss to be
- linked in if `-msim' is not given.
-
-`-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 will ensure 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 will ensure 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 will be generated for jump and
- call insns.
-
-`-mshared-library-id=n'
- Specified the identification number of the ID based shared library
- being compiled. Specifying a value of 0 will generate more
- compact code, specifying other values will force 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 will lie 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' will restore 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 standalone application for multicore Blackfin processor.
- Proper start files and link scripts will be used to support
- multicore. This option defines `__BFIN_MULTICORE'. It can only be
- used with `-mcpu=bf561[-SIREVISION]'. It can be used with
- `-mcorea' or `-mcoreb'. If it's used without `-mcorea' or
- `-mcoreb', single application/dual core programming model is used.
- In this model, the main function of Core B should be named as
- coreb_main. If it's used with `-mcorea' or `-mcoreb', one
- application per core programming model is used. If this option is
- not used, single core application programming model is used.
-
-`-mcorea'
- Build standalone application for Core A of BF561 when using one
- application per core programming model. Proper start files and
- link scripts will be used to support Core A. This option defines
- `__BFIN_COREA'. It must be used with `-mmulticore'.
-
-`-mcoreb'
- Build standalone application for Core B of BF561 when using one
- application per core programming model. Proper start files and
- link scripts will be used to support Core B. This option defines
- `__BFIN_COREB'. When this option is used, coreb_main should be
- used instead of main. It must be used with `-mmulticore'.
-
-`-msdram'
- Build standalone application for SDRAM. Proper start files and
- link scripts will be used to put the application into SDRAM.
- Loader should initialize SDRAM before loading the application into
- SDRAM. This option defines `__BFIN_SDRAM'.
-
-`-micplb'
- Assume that ICPLBs are enabled at runtime. 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.
-
-\1f
-File: gcc.info, Node: CRIS Options, Next: CRX Options, Prev: Blackfin Options, Up: Submodel Options
-
-3.17.5 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 to turn 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) arranges (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 that sets 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 variable 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.
-
-\1f
-File: gcc.info, Node: CRX Options, Next: Darwin Options, Prev: CRIS Options, Up: Submodel Options
-
-3.17.6 CRX Options
-------------------
-
-These options are defined specifically for the CRX ports.
-
-`-mmac'
- Enable the use of multiply-accumulate instructions. Disabled by
- default.
-
-`-mpush-args'
- Push instructions will be used to pass outgoing arguments when
- functions are called. Enabled by default.
-
-\1f
-File: gcc.info, Node: Darwin Options, Next: DEC Alpha Options, Prev: CRX Options, Up: Submodel Options
-
-3.17.7 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 will create
-an object file for the single architecture that it 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 targetting,
-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', will only permit instructions to be
-used that are valid for the subtype of the file it is generating, so
-you cannot put 64-bit instructions in an `ppc750' object file. The
-linker for shared libraries, `/usr/bin/libtool', will fail and print 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',
-will quietly give 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 will be 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 which
- 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 turn around development. Needed to
- enable 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 be loading the build
- output file being linked. See man ld(1) for more information.
-
-`-dynamiclib'
- When passed this option, GCC will produce 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.
-
-\1f
-File: gcc.info, Node: DEC Alpha Options, Next: DEC Alpha/VMS Options, Prev: Darwin Options, Up: Submodel Options
-
-3.17.8 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' will be 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 will 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. Under DEC Unix, this has the effect
- that IEEE-conformant math library routines will be linked in.
-
-`-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 will output the constant as a
- literal and generate code to load it from the data segment at
- runtime.
-
- Use this option to require GCC to construct _all_ integer constants
- using code, even if it takes more instructions (the maximum is
- six).
-
- You would 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.
-
-`-malpha-as'
-`-mgas'
- Select whether to generate code to be assembled by the
- vendor-supplied assembler (`-malpha-as') or by the GNU assembler
- `-mgas'.
-
-`-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 was
- 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 will
- choose the default values for the instruction set from the
- processor you specify. If you do not specify a processor type,
- GCC will default 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 Linux/GNU 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 Linux/GNU 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.
-
-
-\1f
-File: gcc.info, Node: DEC Alpha/VMS Options, Next: FR30 Options, Prev: DEC Alpha Options, Up: Submodel Options
-
-3.17.9 DEC Alpha/VMS Options
-----------------------------
-
-These `-m' options are defined for the DEC Alpha/VMS implementations:
-
-`-mvms-return-codes'
- Return VMS condition codes from main. The default is to return
- POSIX style condition (e.g. error) codes.
-
-\1f
-File: gcc.info, Node: FR30 Options, Next: FRV Options, Prev: DEC Alpha/VMS Options, Up: Submodel Options
-
-3.17.10 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 will fit
- into a 20-bit range.
-
-`-mno-lsim'
- Assume that run-time support has been provided and so there is no
- need to include the simulator library (`libsim.a') on the linker
- command line.
-
-
-\1f
-File: gcc.info, Node: FRV Options, Next: GNU/Linux Options, Prev: FR30 Options, Up: Submodel Options
-
-3.17.11 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, that 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'.
-
-
-\1f
-File: gcc.info, Node: GNU/Linux Options, Next: H8/300 Options, Prev: FRV Options, Up: Submodel Options
-
-3.17.12 GNU/Linux Options
--------------------------
-
-These `-m' options are defined for GNU/Linux targets:
-
-`-mglibc'
- Use the GNU C library instead of uClibc. This is the default
- except on `*-*-linux-*uclibc*' targets.
-
-`-muclibc'
- Use uClibc instead of the GNU C library. This is the default on
- `*-*-linux-*uclibc*' targets.
-
-\1f
-File: gcc.info, Node: H8/300 Options, Next: HPPA Options, Prev: GNU/Linux Options, Up: Submodel Options
-
-3.17.13 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'.
-
-`-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.
-
-\1f
-File: gcc.info, Node: HPPA Options, Next: i386 and x86-64 Options, Prev: H8/300 Options, Up: Submodel Options
-
-3.17.14 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 will
- run 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.
-
-`-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.
-
-`-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 which perform lazy context
- switching of floating point registers. If you use this option and
- attempt to perform floating point operations, the compiler will
- abort.
-
-`-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 which performs faster indirect calls.
-
- This option will 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 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.
-
-`-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 GNU ld specific options. 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 have any affect on 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 HP ld specific options. 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 have any
- affect on 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 will degrade
- 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.
-
-\1f
-File: gcc.info, Node: i386 and x86-64 Options, Next: i386 and x86-64 Windows Options, Prev: HPPA Options, Up: Submodel Options
-
-3.17.15 Intel 386 and AMD x86-64 Options
-----------------------------------------
-
-These `-m' options are defined for the i386 and x86-64 family of
-computers:
-
-`-mtune=CPU-TYPE'
- Tune to CPU-TYPE everything applicable about the generated code,
- except for the ABI and the set of available instructions. The
- choices for CPU-TYPE are:
- _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' 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, the code generated option
- will change to reflect the processors that were most common
- when that version of GCC was 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.
-
- _native_
- This selects the CPU to tune for at compilation time by
- determining the processor type of the compiling machine.
- Using `-mtune=native' will produce code optimized for the
- local machine under the constraints of the selected
- instruction set. Using `-march=native' will enable all
- instruction subsets supported by the local machine (hence the
- result might not run on different machines).
-
- _i386_
- Original Intel's i386 CPU.
-
- _i486_
- Intel's i486 CPU. (No scheduling is implemented for this
- chip.)
-
- _i586, pentium_
- Intel Pentium CPU with no MMX support.
-
- _pentium-mmx_
- Intel PentiumMMX CPU based on Pentium core with MMX
- instruction set support.
-
- _pentiumpro_
- Intel PentiumPro CPU.
-
- _i686_
- Same as `generic', but when used as `march' option, PentiumPro
- instruction set will be used, so the code will run on all
- i686 family chips.
-
- _pentium2_
- Intel Pentium2 CPU based on PentiumPro core with MMX
- instruction set support.
-
- _pentium3, pentium3m_
- Intel Pentium3 CPU based on PentiumPro core with MMX and SSE
- instruction set support.
-
- _pentium-m_
- Low power version of Intel Pentium3 CPU with MMX, SSE and
- SSE2 instruction set support. Used by Centrino notebooks.
-
- _pentium4, pentium4m_
- Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set
- support.
-
- _prescott_
- Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2
- and SSE3 instruction set support.
-
- _nocona_
- Improved version of Intel Pentium4 CPU with 64-bit
- extensions, MMX, SSE, SSE2 and SSE3 instruction set support.
-
- _core2_
- Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
- and SSSE3 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_
- AMD K8 core based CPUs with x86-64 instruction set support.
- (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and
- 64-bit instruction set extensions.)
-
- _k8-sse3, opteron-sse3, athlon64-sse3_
- Improved versions of k8, opteron and athlon64 with SSE3
- instruction set support.
-
- _amdfam10, barcelona_
- AMD Family 10h core based CPUs with x86-64 instruction set
- support. (This supersets MMX, SSE, SSE2, SSE3, SSE4A,
- 3dNOW!, enhanced 3dNOW!, ABM 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 Winchip2 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 CPU with MMX and SSE instruction set support. (No
- scheduling is implemented for this chip.)
-
- _geode_
- Embedded AMD CPU with MMX and 3dNOW! instruction set support.
-
- While picking a specific CPU-TYPE will schedule things
- appropriately for that particular chip, the compiler will not
- generate any code that does not run on the i386 without the
- `-march=CPU-TYPE' option being used.
-
-`-march=CPU-TYPE'
- Generate instructions for the machine type CPU-TYPE. The choices
- for CPU-TYPE are the same as for `-mtune'. Moreover, specifying
- `-march=CPU-TYPE' implies `-mtune=CPU-TYPE'.
-
-`-mcpu=CPU-TYPE'
- A deprecated synonym for `-mtune'.
-
-`-mfpmath=UNIT'
- Generate floating point arithmetics for selected unit UNIT. The
- choices for UNIT are:
-
- `387'
- Use the standard 387 floating point coprocessor present
- majority of chips and emulated otherwise. Code compiled with
- this option will run almost everywhere. The temporary
- results are computed in 80bit precision instead of 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
- Pentium3 and newer chips, in the AMD line by Athlon-4,
- Athlon-xp and Athlon-mp chips. The earlier version of SSE
- instruction set supports only single precision arithmetics,
- thus the double and extended precision arithmetics is still
- done using 387. Later version, present only in Pentium4 and
- the future AMD x86-64 chips supports double precision
- arithmetics too.
-
- For the i386 compiler, you need to 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 80bit.
-
- 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 double 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
- instable performance.
-
-`-masm=DIALECT'
- Output asm instructions using selected DIALECT. Supported choices
- are `intel' or `att' (the default one). Darwin does not support
- `intel'.
-
-`-mieee-fp'
-`-mno-ieee-fp'
- Control whether or not the compiler uses IEEE floating point
- comparisons. These handle correctly 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 will always have an FPU and so the
- instruction will not need emulation. As of revision 2.6.1, 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 will produce
- 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 will be aligned differently than the
- published application binary interface specifications for the 386
- and will not be 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) would prefer `long double'
- to be aligned to an 8 or 16 byte boundary. In arrays or structures
- conforming to the ABI, this would not be possible. So specifying a
- `-m128bit-long-double' will align `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 to be 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,
- the structures and arrays containing `long double' variables will
- change their size as well as function calling convention for
- function taking `long double' will be modified. Hence they will
- not be binary compatible with arrays or structures in code
- compiled without that switch.
-
-`-mlarge-data-threshold=NUMBER'
- When `-mcmodel=medium' is specified, the data greater than
- THRESHOLD are placed in large data section. This value must be the
- same across all object 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 will be generated for calls to those functions.
-
- In addition, seriously incorrect code will result 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.
-
-`-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 will generate an alternate prologue and epilogue that
- realigns the runtime stack if necessary. This supports mixing
- legacy codes that keep a 4-byte aligned stack with modern codes
- that keep a 16-byte stack 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).
-
-`-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' will be used.
-
- On Pentium and PentiumPro, `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 will most likely misalign 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'
-`-maes'
-`-mno-aes'
-`-mpclmul'
-`-mno-pclmul'
-`-msse4a'
-`-mno-sse4a'
-`-msse5'
-`-mno-sse5'
-`-m3dnow'
-`-mno-3dnow'
-`-mpopcnt'
-`-mno-popcnt'
-`-mabm'
-`-mno-abm'
- These switches enable or disable the use of instructions in the
- MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AES, PCLMUL, SSE4A,
- SSE5, ABM 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 have SSE/SSE2 instructions generated 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 will enable GCC to use these extended instructions in
- generated code, even without `-mfpmath=sse'. Applications which
- perform runtime 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.
-
-`-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.
-
-`-mcx16'
- This option will enable GCC to use CMPXCHG16B instruction in
- generated code. CMPXCHG16B allows for atomic operations on
- 128-bit double quadword (or oword) data types. This is useful for
- high resolution counters that could be updated by multiple
- processors (or cores). This instruction is generated as part of
- atomic built-in functions: see *note Atomic Builtins:: for details.
-
-`-msahf'
- This option will enable GCC to use SAHF instruction in generated
- 64-bit code. Early Intel CPUs with Intel 64 lacked LAHF and SAHF
- instructions supported by AMD64 until introduction of Pentium 4 G1
- step in December 2005. LAHF and SAHF are load and store
- instructions, respectively, for certain status flags. In 64-bit
- mode, SAHF instruction is used to optimize `fmod', `drem' or
- `remainder' built-in functions: see *note Other Builtins:: for
- details.
-
-`-mrecip'
- This option will enable GCC to use 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).
-
-`-mveclibabi=TYPE'
- Specifies the ABI type to use for vectorizing intrinsics using an
- external library. Supported types are `svml' for the Intel short
- vector math library and `acml' for the AMD math core library style
- of interfacing. GCC will currently emit 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 corresponding function type when
- `-mveclibabi=acml' is used. Both `-ftree-vectorize' and
- `-funsafe-math-optimizations' have to be enabled. A SVML or ACML
- ABI compatible library will have to be specified at link time.
-
-`-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 will be computed in the function prologue. This is
- faster on most modern CPUs because of reduced dependencies,
- improved scheduling and reduced stack usage when 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 `Mingw32'. Code that
- relies 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 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 destination is
- known to be aligned at least to 4 byte boundary. This enables
- more inlining, increase code size, but may improve performance of
- code that depends on fast memcpy, strlen and memset for short
- lengths.
-
-`-minline-stringops-dynamically'
- For string operation of unknown size, inline runtime checks so for
- small blocks inline code is used, while for large blocks library
- call is used.
-
-`-mstringop-strategy=ALG'
- Overwrite internal decision heuristic about particular algorithm
- to inline string operation with. The allowed values are
- `rep_byte', `rep_4byte', `rep_8byte' for expanding using i386
- `rep' prefix of specified size, `byte_loop', `loop',
- `unrolled_loop' for expanding inline loop, `libcall' for always
- expanding library call.
-
-`-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.
-
-`-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 legal depends on the operating system, and whether it maps the
- segment to cover the entire TLS area.
-
- For systems that use GNU libc, the default is on.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Enable automatic generation of fused floating point multiply-add
- instructions if the ISA supports such instructions. The
- -mfused-madd option is on by default. The fused multiply-add
- instructions have a different rounding behavior compared to
- executing a multiply followed by an add.
-
-`-msse2avx'
-`-mno-sse2avx'
- Specify that the assembler should encode SSE instructions with VEX
- prefix. The option `-mavx' turns this on by default.
-
- These `-m' switches are supported in addition to the above on AMD
-x86-64 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 and generates
- code that runs on any i386 system. The 64-bit environment sets
- int to 32 bits and long and pointer to 64 bits and generates code
- for AMD's x86-64 architecture. For darwin only the -m64 option
- turns off the `-fno-pic' and `-mdynamic-no-pic' options.
-
-`-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 will not be 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.
-
-\1f
-File: gcc.info, Node: IA-64 Options, Next: M32C Options, Prev: i386 and x86-64 Windows Options, Up: Submodel Options
-
-3.17.16 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.
-
-`-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.
-
-`-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-dwarf2-asm'
-`-mdwarf2-asm'
- Don't (or do) generate assembler code for the DWARF2 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 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.
-
-`-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.
-
-`-mt'
-`-pthread'
- Add support for multithreading using the POSIX threads library.
- This option sets flags for both the preprocessor and linker. It
- does not affect the thread safety of object code produced by the
- compiler or that of libraries supplied with it. These are HP-UX
- specific flags.
-
-`-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 will
- result in generation of the 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 will
- result in generation of the 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 will result 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'.
-
-`-msched-ldc'
-`-mno-sched-ldc'
- (En/Dis)able use of simple data speculation checks ld.c . If
- disabled, only chk.a instructions will be emitted to check data
- speculative loads. The default is 'enable'.
-
-`-mno-sched-control-ldc'
-`-msched-control-ldc'
- (Dis/En)able use of ld.c instructions to check control speculative
- loads. If enabled, in case of control speculative load with no
- speculatively scheduled dependent instructions this load will be
- emitted as ld.sa and ld.c will be used to check it. The default
- is 'disable'.
-
-`-mno-sched-spec-verbose'
-`-msched-spec-verbose'
- (Dis/En)able printing of the information about speculative motions.
-
-`-mno-sched-prefer-non-data-spec-insns'
-`-msched-prefer-non-data-spec-insns'
- If enabled, data speculative instructions will be chosen for
- schedule only if there are no other choices at the moment. This
- will make 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 will be chosen for
- schedule only if there are no other choices at the moment. This
- will make 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 will be considered during
- computation of the instructions priorities. This will make the
- use of the speculation a bit more conservative. The default is
- 'disable'.
-
-
-\1f
-File: gcc.info, Node: M32C Options, Next: M32R/D Options, Prev: IA-64 Options, Up: Submodel Options
-
-3.17.17 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 will use
- during code generation. These pseudo-registers will be 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 the default
- runtime libraries gcc builds.
-
-
-\1f
-File: gcc.info, Node: M32R/D Options, Next: M680x0 Options, Prev: M32C Options, Up: Submodel Options
-
-3.17.18 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 will generate `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 will generate `seth/add3' instructions to load their
- addresses), and assume subroutines may not be reachable with the
- `bl' instruction (the compiler will generate the much slower
- `seth/add3/jl' instruction sequence).
-
-`-msdata=none'
- Disable use of the small data area. Variables will be 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 will give an error message--incorrect code will
- not be 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 will be
- preferred over conditional code, if it is 2, then the opposite will
- apply.
-
-`-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 will only be used if a trap is not available.
-
-`-mno-flush-func'
- Indicates that there is no OS function for flushing the cache.
-
-
-\1f
-File: gcc.info, Node: M680x0 Options, Next: M68hc1x Options, Prev: M32R/D Options, Up: Submodel Options
-
-3.17.19 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*
- `51qe' `51qe'
- `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'
- `5235' `5232' `5233' `5234' `5235' `523x'
- `5249' `5249'
- `5250' `5250'
- `5271' `5270' `5271'
- `5272' `5272'
- `5275' `5274' `5275'
- `5282' `5280' `5281' `5282' `528x'
- `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 which 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 which 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 will be generated for calls to those functions.
-
- In addition, seriously incorrect code will result 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 will align
- 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 will be
- 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'
- Specified the identification number of the ID based shared library
- being compiled. Specifying a value of 0 will generate more
- compact code, specifying other values will force 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.
-
-
-\1f
-File: gcc.info, Node: M68hc1x Options, Next: MCore Options, Prev: M680x0 Options, Up: Submodel Options
-
-3.17.20 M68hc1x Options
------------------------
-
-These are the `-m' options defined for the 68hc11 and 68hc12
-microcontrollers. The default values for these options depends on
-which style of microcontroller was selected when the compiler was
-configured; the defaults for the most common choices are given below.
-
-`-m6811'
-`-m68hc11'
- Generate output for a 68HC11. This is the default when the
- compiler is configured for 68HC11-based systems.
-
-`-m6812'
-`-m68hc12'
- Generate output for a 68HC12. This is the default when the
- compiler is configured for 68HC12-based systems.
-
-`-m68S12'
-`-m68hcs12'
- Generate output for a 68HCS12.
-
-`-mauto-incdec'
- Enable the use of 68HC12 pre and post auto-increment and
- auto-decrement addressing modes.
-
-`-minmax'
-`-nominmax'
- Enable the use of 68HC12 min and max instructions.
-
-`-mlong-calls'
-`-mno-long-calls'
- Treat all calls as being far away (near). If calls are assumed to
- be far away, the compiler will use the `call' instruction to call
- a function and the `rtc' instruction for returning.
-
-`-mshort'
- Consider type `int' to be 16 bits wide, like `short int'.
-
-`-msoft-reg-count=COUNT'
- Specify the number of pseudo-soft registers which are used for the
- code generation. The maximum number is 32. Using more pseudo-soft
- register may or may not result in better code depending on the
- program. The default is 4 for 68HC11 and 2 for 68HC12.
-
-
-\1f
-File: gcc.info, Node: MCore Options, Next: MIPS Options, Prev: M68hc1x Options, Up: Submodel Options
-
-3.17.21 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 four 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 run-time 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 which 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.
-
-
-\1f
-File: gcc.info, Node: MIPS Options, Next: MMIX Options, Prev: MCore Options, Up: Submodel Options
-
-3.17.22 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 will run 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', `74kc',
- `74kf2_1', `74kf1_1', `74kf3_2', `loongson2e', `loongson2f', `m4k',
- `octeon', `orion', `r2000', `r3000', `r3900', `r4000', `r4400',
- `r4600', `r4650', `r6000', `r8000', `rm7000', `rm9000', `r10000',
- `r12000', `r14000', `r16000', `sb1', `sr71000', `vr4100',
- `vr4111', `vr4120', `vr4130', `vr4300', `vr5000', `vr5400',
- `vr5500' and `xlr'. 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).
-
- Native Linux/GNU toolchains also support 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' will set `_MIPS_ARCH'
- to `"r2000"' and define the macro `_MIPS_ARCH_R2000'.
-
- Note that the `_MIPS_ARCH' macro uses the processor names given
- above. In other words, it will have the full prefix and will 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 will optimize for the processor
- specified by `-march'. By using `-march' and `-mtune' together,
- it is possible to generate code that will run 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 targetting a
- MIPS32 or MIPS64 architecture, it will make 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-mips16'
-`-mno-interlink-mips16'
- Require (do not require) that non-MIPS16 code be link-compatible
- with MIPS16 code.
-
- For example, non-MIPS16 code cannot jump directly to MIPS16 code;
- it must either use a call or an indirect jump.
- `-minterlink-mips16' therefore disables direct jumps unless GCC
- knows that the target of the jump is not MIPS16.
-
-`-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' will
- generally make 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 will only work if the GOT
- is smaller than about 64k. Anything larger will cause 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'. It
- should then work with very large GOTs, although it will also be
- less efficient, since it will take 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.
-
-`-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.
-
-`-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 will use 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'.
-
-`-mmt'
-`-mno-mt'
- Use (do not use) MT Multithreading 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 access the
- data more efficiently; 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 will be in a
- small data section if 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 will pass an unknown value in `$gp'. (In
- such situations, the boot monitor itself would usually be 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.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Enable (disable) use of the floating point multiply-accumulate
- instructions, when they are available. The default is
- `-mfused-madd'.
-
- 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.
-
-`-nocpp'
- Tell the MIPS assembler to not run its preprocessor over user
- assembler files (with a `.s' suffix) when assembling them.
-
-`-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-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 will
- avoid 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 was 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 will overwrite 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 will 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 which implement those architectures;
- for those, Branch Likely instructions will 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 we
- schedule FP instructions 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 will align 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'.
-
-\1f
-File: gcc.info, Node: MMIX Options, Next: MN10300 Options, Prev: MIPS Options, Up: Submodel Options
-
-3.17.23 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.
-
-\1f
-File: gcc.info, Node: MN10300 Options, Next: PDP-11 Options, Prev: MMIX Options, Up: Submodel Options
-
-3.17.24 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 which uses features specific to the AM33 processor.
-
-`-mno-am33'
- Do not generate code which uses features specific to the AM33
- processor. This is the default.
-
-`-mreturn-pointer-on-d0'
- When generating a function which 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
- would 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.
-
-\1f
-File: gcc.info, Node: PDP-11 Options, Next: picoChip Options, Prev: MN10300 Options, Up: Submodel Options
-
-3.17.25 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.
-
-`-msplit'
- Generate code for a system with split I&D.
-
-`-mno-split'
- Generate code for a system without split I&D. 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'.
-
-\1f
-File: gcc.info, Node: picoChip Options, Next: PowerPC Options, Prev: PDP-11 Options, Up: Submodel Options
-
-3.17.26 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 will run on any of the other AE types. The code
- will not be as efficient as it would be if compiled for a specific
- AE type, and some types of operation (e.g., multiplication) will
- 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 will generate 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 which
- 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 will be generated
- indicating to the programmer that they should rewrite the code to
- avoid byte operations, or to target an AE type which has the
- necessary hardware support. This option enables the warning to be
- turned off.
-
-
-\1f
-File: gcc.info, Node: PowerPC Options, Next: RS/6000 and PowerPC Options, Prev: picoChip Options, Up: Submodel Options
-
-3.17.27 PowerPC Options
------------------------
-
-These are listed under *Note RS/6000 and PowerPC Options::.
-
-\1f
-File: gcc.info, Node: RS/6000 and PowerPC Options, Next: S/390 and zSeries Options, Prev: PowerPC Options, Up: Submodel Options
-
-3.17.28 IBM RS/6000 and PowerPC Options
----------------------------------------
-
-These `-m' options are defined for the IBM RS/6000 and PowerPC:
-`-mpower'
-`-mno-power'
-`-mpower2'
-`-mno-power2'
-`-mpowerpc'
-`-mno-powerpc'
-`-mpowerpc-gpopt'
-`-mno-powerpc-gpopt'
-`-mpowerpc-gfxopt'
-`-mno-powerpc-gfxopt'
-`-mpowerpc64'
-`-mno-powerpc64'
-`-mmfcrf'
-`-mno-mfcrf'
-`-mpopcntb'
-`-mno-popcntb'
-`-mfprnd'
-`-mno-fprnd'
-`-mcmpb'
-`-mno-cmpb'
-`-mmfpgpr'
-`-mno-mfpgpr'
-`-mhard-dfp'
-`-mno-hard-dfp'
- GCC supports two related instruction set architectures for the
- RS/6000 and PowerPC. The "POWER" instruction set are those
- instructions supported by the `rios' chip set used in the original
- RS/6000 systems and the "PowerPC" instruction set is the
- architecture of the Freescale MPC5xx, MPC6xx, MPC8xx
- microprocessors, and the IBM 4xx, 6xx, and follow-on
- microprocessors.
-
- Neither architecture is a subset of the other. However there is a
- large common subset of instructions supported by both. An MQ
- register is included in processors supporting the POWER
- architecture.
-
- 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.
-
- The `-mpower' option allows GCC to generate instructions that are
- found only in the POWER architecture and to use the MQ register.
- Specifying `-mpower2' implies `-power' and also allows GCC to
- generate instructions that are present in the POWER2 architecture
- but not the original POWER architecture.
-
- The `-mpowerpc' option allows GCC to generate instructions that
- are found only in the 32-bit subset of the PowerPC architecture.
- Specifying `-mpowerpc-gpopt' implies `-mpowerpc' and also allows
- GCC to use the optional PowerPC architecture instructions in the
- General Purpose group, including floating-point square root.
- Specifying `-mpowerpc-gfxopt' implies `-mpowerpc' and also 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 `-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'.
-
- If you specify both `-mno-power' and `-mno-powerpc', GCC will use
- only the instructions in the common subset of both architectures
- plus some special AIX common-mode calls, and will not use the MQ
- register. Specifying both `-mpower' and `-mpowerpc' permits GCC
- to use any instruction from either architecture and to allow use
- of the MQ register; specify this for the Motorola MPC601.
-
-`-mnew-mnemonics'
-`-mold-mnemonics'
- Select which mnemonics to use in the generated assembler code.
- With `-mnew-mnemonics', GCC uses the assembler mnemonics defined
- for the PowerPC architecture. With `-mold-mnemonics' it uses the
- assembler mnemonics defined for the POWER architecture.
- Instructions defined in only one architecture have only one
- mnemonic; GCC uses that mnemonic irrespective of which of these
- options is specified.
-
- GCC defaults to the mnemonics appropriate for the architecture in
- use. Specifying `-mcpu=CPU_TYPE' sometimes overrides the value of
- these option. Unless you are building a cross-compiler, you
- should normally not specify either `-mnew-mnemonics' or
- `-mold-mnemonics', but should instead accept the default.
-
-`-mcpu=CPU_TYPE'
- Set architecture type, register usage, choice of mnemonics, and
- instruction scheduling parameters for machine type CPU_TYPE.
- Supported values for CPU_TYPE are `401', `403', `405', `405fp',
- `440', `440fp', `464', `464fp', `505', `601', `602', `603',
- `603e', `604', `604e', `620', `630', `740', `7400', `7450', `750',
- `801', `821', `823', `860', `970', `8540', `e300c2', `e300c3',
- `e500mc', `ec603e', `G3', `G4', `G5', `power', `power2', `power3',
- `power4', `power5', `power5+', `power6', `power6x', `power7'
- `common', `powerpc', `powerpc64', `rios', `rios1', `rios2', `rsc',
- and `rs64'.
-
- `-mcpu=common' selects a completely generic processor. Code
- generated under this option will run on any POWER or PowerPC
- processor. GCC will use only the instructions in the common
- subset of both architectures, and will not use the MQ register.
- GCC assumes a generic processor model for scheduling purposes.
-
- `-mcpu=power', `-mcpu=power2', `-mcpu=powerpc', and
- `-mcpu=powerpc64' specify generic POWER, POWER2, pure 32-bit
- PowerPC (i.e., not MPC601), 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 will run 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
- -mnew-mnemonics -mpopcntb -mpower -mpower2 -mpowerpc64
- -mpowerpc-gpopt -mpowerpc-gfxopt -msingle-float -mdouble-float
- -msimple-fpu -mstring -mmulhw -mdlmzb -mmfpgpr
-
- The particular options set for any particular CPU will vary 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, register usage, or
- choice of mnemonics, as `-mcpu=CPU_TYPE' would. The same values
- for CPU_TYPE are used for `-mtune' as for `-mcpu'. If both are
- specified, the code generated will use the architecture,
- registers, and mnemonics set by `-mcpu', but the scheduling
- parameters set by `-mtune'.
-
-`-mswdiv'
-`-mno-swdiv'
- Generate code to compute division as reciprocal estimate and
- iterative refinement, creating opportunities for increased
- throughput. This feature requires: optional PowerPC Graphics
- instruction set for single precision and FRE instruction for
- double precision, assuming divides cannot generate user-visible
- traps, and the domain values not include Infinities, denormals or
- zero denominator.
-
-`-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.
-
-`-mvrsave'
-`-mno-vrsave'
- Generate VRSAVE instructions when generating AltiVec code.
-
-`-mgen-cell-microcode'
- Generate Cell microcode instructions
-
-`-mwarn-cell-microcode'
- Warning when a Cell microcode instruction is going to 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-exec .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.
-
-`-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 will allocate at least one TOC entry
- for each unique non-automatic variable reference in your program.
- GCC will also place 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 will produce 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' and `-mpowerpc', 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 which
- 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'
- Specify type of floating point unit. Valid values 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 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 the instructions usage 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 the
- instructions usage 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 targetting
- 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 is used.
-
-`-mmulhw'
-`-mno-mulhw'
- Generate code that uses (does not use) the half-word multiply and
- multiply-accumulate instructions on the IBM 405, 440 and 464
- processors. These instructions are generated by default when
- targetting those processors.
-
-`-mdlmzb'
-`-mno-dlmzb'
- Generate code that uses (does not use) the string-search `dlmzb'
- instruction on the IBM 405, 440 and 464 processors. This
- instruction is generated by default when targetting 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 would be aligned to a 4 byte
- boundary and have a size of 4 bytes. By using `-mno-bit-align',
- the structure would be aligned to a 1 byte boundary and be one
- byte in size.
-
-`-mno-strict-align'
-`-mstrict-align'
- On System V.4 and embedded PowerPC systems do not (do) assume that
- unaligned memory references will be handled by the system.
-
-`-mrelocatable'
-`-mno-relocatable'
- On embedded PowerPC systems generate code that allows (does not
- allow) the program to be relocated to a different address at
- runtime. If you use `-mrelocatable' on any module, all objects
- linked together must be compiled with `-mrelocatable' or
- `-mrelocatable-lib'.
-
-`-mrelocatable-lib'
-`-mno-relocatable-lib'
- On embedded PowerPC systems generate code that allows (does not
- allow) the program to be relocated to a different address at
- runtime. Modules compiled with `-mrelocatable-lib' can be linked
- with either modules compiled without `-mrelocatable' and
- `-mrelocatable-lib' or with modules compiled with 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.
-
-`-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/2 to assign
- NO/HIGHEST/SECOND-HIGHEST 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 which latency >= NUMBER is costly.
-
-`-minsert-sched-nops=SCHEME'
- This option controls which nop insertion scheme will be 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 which 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 adheres 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'
- Specify both `-mcall-sysv' and `-meabi' options.
-
-`-mcall-sysv-noeabi'
- Specify both `-mcall-sysv' and `-mno-eabi' options.
-
-`-mcall-solaris'
- On System V.4 and embedded PowerPC systems compile code for the
- Solaris operating system.
-
-`-mcall-linux'
- On System V.4 and embedded PowerPC systems compile code for the
- Linux-based GNU system.
-
-`-mcall-gnu'
- On System V.4 and embedded PowerPC systems compile code for the
- Hurd-based GNU system.
-
-`-mcall-netbsd'
- On System V.4 and embedded PowerPC systems compile code for the
- NetBSD 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.
-
-`-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 Booke 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.
-
-`-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 were
- passed in the floating point registers in case the function takes
- a variable arguments. With `-mprototype', only calls to
- prototyped variable argument functions will 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 to 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, do not call an
- initialization function from `main', and the `-msdata' option will
- only use `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.
-
-`-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 more
- expensive calling sequence is required. This is required for calls
- further than 32 megabytes (33,554,432 bytes) from the current
- location. A short call will be 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' will generate "jbsr
- callee, L42", plus a "branch island" (glue code). The two target
- addresses represent the callee and the "branch island". The
- Darwin/PPC linker will prefer the first address and generate a "bl
- callee" if the PPC "bl" instruction will reach the callee directly;
- otherwise, the linker will generate "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, we may cause GCC to ignore all longcall
- specifications when the linker is known to generate glue.
-
-`-pthread'
- Adds support for multithreading with the "pthreads" library. This
- option sets flags for both the preprocessor and linker.
-
-
-\1f
-File: gcc.info, Node: S/390 and zSeries Options, Next: Score Options, Prev: RS/6000 and PowerPC Options, Up: Submodel Options
-
-3.17.29 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' will be 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' will be 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
- 64bit 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 will run 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 which 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 s390 back end emits additional
- instructions in the function prologue which trigger a trap if the
- stack size is STACK-GUARD bytes above the STACK-SIZE (remember
- that the stack on s390 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.
-
-\1f
-File: gcc.info, Node: Score Options, Next: SH Options, Prev: S/390 and zSeries Options, Up: Submodel Options
-
-3.17.30 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 generate bcnz instruction.
-
-`-muls'
- Enable generate unaligned load and store instruction.
-
-`-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.
-
-\1f
-File: gcc.info, Node: SH Options, Next: SPARC Options, Prev: Score Options, Up: Submodel Options
-
-3.17.31 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.
-
-`-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 will 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'.
-
-`-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 except for `sh-symbianelf'.
-
-`-mnomacsave'
- Mark the `MAC' register as call-clobbered, even if `-mhitachi' is
- given.
-
-`-mieee'
- Increase IEEE-compliance of floating-point code. At the moment,
- this is equivalent to `-fno-finite-math-only'. When generating 16
- bit SH opcodes, getting IEEE-conforming results for comparisons of
- NANs / infinities incurs extra overhead in every floating point
- comparison, therefore the default is set to `-ffinite-math-only'.
-
-`-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 will
- manipulate the instruction cache address array directly with an
- associative write. This not only requires privileged mode, but it
- will also fail 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.
-
-`-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; 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 use for SHmedia code. STRATEGY must
- be one of: call, call2, fp, inv, inv:minlat, inv20u, inv20l,
- inv:call, inv:call2, inv:fp . "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" is a variant of "inv" where if no cse / 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 / code hoisting optimizations.
- "inv:call", "inv:call2" and "inv:fp" all 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 fp operations
- or a call is not possible in that case. "inv20u" and "inv20l" are
- variants of the "inv:minlat" strategy. In the case that the
- inverse calculation was nor 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.
-
-`-mdivsi3_libfunc=NAME'
- Set the name of the library function used for 32 bit signed
- division to NAME. This only affect the name used in the call and
- inv:call division strategies, and the compiler will still expect
- the same sets of input/output/clobbered registers as if this
- option was 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.
-
-`-madjust-unroll'
- Throttle unrolling to avoid thrashing target registers. This
- option only has an effect if the gcc code base supports the
- TARGET_ADJUST_UNROLL_MAX target hook.
-
-`-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 will generally generate
- 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 ptabs / ptrel before a
- branch, or hoist it 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 will be done before
- testing against -1. That means that all the constructors will be
- run a bit quicker, 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 the user specifies a specific cost with `-mgettrcost',
- -mno-pt-fixed also implies `-mgettrcost=100'; this deters register
- allocation using target registers for storing ordinary integers.
-
-`-minvalid-symbols'
- Assume symbols might be invalid. Ordinary function symbols
- generated by the compiler will always be 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 will cause
- ptabs / ptrel to trap. This option is only meaningful when
- `-mno-pt-fixed' is in effect. It will then prevent
- cross-basic-block cse, hoisting and most scheduling of symbol
- loads. The default is `-mno-invalid-symbols'.
-
-\1f
-File: gcc.info, Node: SPARC Options, Next: SPU Options, Prev: SH Options, Up: Submodel Options
-
-3.17.32 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.
- 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.
-
-`-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 will not be directly in
- line with the rules of the ABI.
-
-`-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 will 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'.
-
- This option is only available on SunOS and Solaris.
-
-`-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', `sparclite',
- `f930', `f934', `hypersparc', `sparclite86x', `sparclet',
- `tsc701', `v9', `ultrasparc', `ultrasparc3', `niagara' and
- `niagara2'.
-
- 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
- sparclite: f930, f934, sparclite86x
- sparclet: tsc701
- v9: ultrasparc, ultrasparc3, niagara, niagara2
-
- 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.
-
-`-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' would.
-
- 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', `f930', `f934', `sparclite86x',
- `tsc701', `ultrasparc', `ultrasparc3', `niagara', and `niagara2'.
-
-`-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-bit 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'.
-
- These `-m' options are supported in addition to the above on SPARC-V9
-processors in 64-bit environments:
-
-`-mlittle-endian'
- Generate code for a processor running in little-endian mode. It
- is only available for a few configurations and most notably not on
- Solaris and Linux.
-
-`-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=medlow'
- Generate code for 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.
-
-`-mcmodel=medmid'
- Generate code for 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.
-
-`-mcmodel=medany'
- Generate code for 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.
-
-`-mcmodel=embmedany'
- Generate code for 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.
-
-`-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.
-
- These switches are supported in addition to the above on Solaris:
-
-`-threads'
- Add support for multithreading using the Solaris 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.
-
-`-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'.
-
-\1f
-File: gcc.info, Node: SPU Options, Next: System V Options, Prev: SPARC Options, Up: Submodel Options
-
-3.17.33 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 will give an error when it generates code that
- requires a dynamic relocation. `-mno-error-reloc' disables the
- error, `-mwarn-reloc' will generate a warning instead.
-
-`-msafe-dma'
-`-munsafe-dma'
- Instructions which initiate or test completion of DMA must not be
- reordered with respect to loads and stores of the memory which is
- being accessed. Users typically address this problem using the
- volatile keyword, but that can lead to inefficient code in places
- where the memory is known to not change. Rather than mark the
- memory as volatile we treat the DMA instructions as potentially
- effecting all memory. With `-munsafe-dma' users must use the
- volatile keyword to protect memory accesses.
-
-`-mbranch-hints'
- By default, GCC will generate a branch hint instruction to avoid
- pipeline stalls for always taken or probably taken branches. A
- hint will not be 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 will link 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 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.
-
-`-mdual-nops'
-`-mdual-nops=N'
- By default, GCC will insert nops to increase dual issue when it
- expects it to increase performance. N can be a value from 0 to
- 10. A smaller N will insert 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
- effecting. GCC will insert up to N nops to enforce this,
- otherwise it will 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 effecting. By
- default, GCC makes sure it is within 125.
-
-`-msafe-hints'
- Work around a hardware bug which causes the SPU to stall
- indefinitely. By default, GCC will insert the `hbrp' instruction
- to make sure this stall won't happen.
-
-
-\1f
-File: gcc.info, Node: System V Options, Next: V850 Options, Prev: SPU Options, Up: Submodel Options
-
-3.17.34 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.
-
-\1f
-File: gcc.info, Node: V850 Options, Next: VAX Options, Prev: System V Options, Up: Submodel Options
-
-3.17.35 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 will always load the functions address
- up into a register, and call 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.
-
-`-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 will cause r2 and r5 to be used in the code generated
- by the compiler. This setting is the default.
-
-`-mno-app-regs'
- This option will cause r2 and r5 to be treated as fixed registers.
-
-`-mv850e1'
- Specify that the target processor is the V850E1. The preprocessor
- constants `__v850e1__' and `__v850e__' will be defined if this
- option is used.
-
-`-mv850e'
- Specify that the target processor is the V850E. The preprocessor
- constant `__v850e__' will be defined if this option is used.
-
- If neither `-mv850' nor `-mv850e' nor `-mv850e1' are defined then
- a default target processor will be chosen and the relevant
- `__v850*__' preprocessor constant will be defined.
-
- The preprocessor constants `__v850' and `__v851__' are always
- defined, regardless of which processor variant is the target.
-
-`-mdisable-callt'
- This option will suppress generation of the CALLT instruction for
- the v850e and v850e1 flavors of the v850 architecture. The
- default is `-mno-disable-callt' which allows the CALLT instruction
- to be used.
-
-
-\1f
-File: gcc.info, Node: VAX Options, Next: VxWorks Options, Prev: V850 Options, Up: Submodel Options
-
-3.17.36 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 you will
- assemble with the GNU assembler.
-
-`-mg'
- Output code for g-format floating point numbers instead of
- d-format.
-
-\1f
-File: gcc.info, Node: VxWorks Options, Next: x86-64 Options, Prev: VAX Options, Up: Submodel Options
-
-3.17.37 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.
-
-\1f
-File: gcc.info, Node: x86-64 Options, Next: Xstormy16 Options, Prev: VxWorks Options, Up: Submodel Options
-
-3.17.38 x86-64 Options
-----------------------
-
-These are listed under *Note i386 and x86-64 Options::.
-
-\1f
-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.39 i386 and x86-64 Windows Options
----------------------------------------
-
-These additional options are available for Windows targets:
-
-`-mconsole'
- This option is available for Cygwin and MinGW targets. It
- 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 is the default behaviour
- for Cygwin and MinGW targets.
-
-`-mcygwin'
- This option is available for Cygwin targets. It specifies that
- the Cygwin internal interface is to be used for predefined
- preprocessor macros, C runtime libraries and related linker paths
- and options. For Cygwin targets this is the default behaviour.
- This option is deprecated and will be removed in a future release.
-
-`-mno-cygwin'
- This option is available for Cygwin targets. It specifies that
- the MinGW internal interface is to be used instead of Cygwin's, by
- setting MinGW-related predefined macros and linker paths and
- default library options. This option is deprecated and will be
- removed in a future release.
-
-`-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.
-
-`-mwin32'
- This option is available for Cygwin and MinGW targets. It
- specifies that the typical Windows pre-defined 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.
-
- See also under *note i386 and x86-64 Options:: for standard options.
-
-\1f
-File: gcc.info, Node: Xstormy16 Options, Next: Xtensa Options, Prev: x86-64 Options, Up: Submodel Options
-
-3.17.40 Xstormy16 Options
--------------------------
-
-These options are defined for Xstormy16:
-
-`-msim'
- Choose startup files and linker script suitable for the simulator.
-
-\1f
-File: gcc.info, Node: Xtensa Options, Next: zSeries Options, Prev: Xstormy16 Options, Up: Submodel Options
-
-3.17.41 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.
-
-`-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 will be
- performed. The default is `-mtarget-align'. These options do not
- affect the treatment of auto-aligned instructions like `LOOP',
- which the assembler will always align, either by widening density
- instructions or by inserting no-op 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
- will still show direct call instructions--look at the disassembled
- object code to see the actual instructions. Note that the
- assembler will use an indirect call for every cross-file call, not
- just those that really will be out of range.
-
-\1f
-File: gcc.info, Node: zSeries Options, Prev: Xtensa Options, Up: Submodel Options
-
-3.17.42 zSeries Options
------------------------
-
-These are listed under *Note S/390 and zSeries Options::.
-
-\1f
-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' would be `-fno-foo'. 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 `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.
-
-`-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 will
- generate 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 will
- enable it by default for languages like C++ which normally require
- exception handling, and disable 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'.
-
-`-funwind-tables'
- Similar to `-fexceptions', except that it will just generate any
- needed static data, but will not affect the generated code in any
- other way. You will normally not enable this option; instead, a
- language processor that needs this handling would enable it on
- your behalf.
-
-`-fasynchronous-unwind-tables'
- Generate unwind table in dwarf2 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).
-
-`-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
- will be equivalent to the smallest integer type which 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 will 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 which 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 that was 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.
-
-`-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 will be 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
- which 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 will not save and restore the register REG.
-
- It is an error to used 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 will produce
- 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 will save
- and restore the register REG if they use it.
-
- It is an error to used 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 will produce
- disastrous results.
-
- A different sort of disaster will result 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 will be 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 will be 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 will 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 anyways,
- 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 will not be 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'
- will exclude 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.
-
-`-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 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 will
- always be 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, the performances of
- the code are 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 the stack would grow beyond the value, a signal is
- raised. 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.
-
-`-fargument-alias'
-`-fargument-noalias'
-`-fargument-noalias-global'
-`-fargument-noalias-anything'
- Specify the possible relationships among parameters and between
- parameters and global data.
-
- `-fargument-alias' specifies that arguments (parameters) may alias
- each other and may alias global storage.
- `-fargument-noalias' specifies that arguments do not alias each
- other, but may alias global storage.
- `-fargument-noalias-global' specifies that arguments do not alias
- each other and do not alias global storage.
- `-fargument-noalias-anything' specifies that arguments do not
- alias any other storage.
-
- Each language will automatically use whatever option is required by
- the language standard. You should not need to use these options
- yourself.
-
-`-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'.
-
- 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 will be 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 ie;
- 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 will be `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 DLL's 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 ie;
- 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 will 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 will be
- thrown between DSOs must be explicitly marked with default
- visibility so that the `type_info' nodes will be unified between
- the DSOs.
-
- An overview of these techniques, their benefits and how to use them
- is at `http://gcc.gnu.org/wiki/Visibility'.
-
-
-\1f
-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 that allow 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 would otherwise be
- 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_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 will attempt to figure out an
- appropriate prefix to use based on the pathname it was 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 will search
- `foo/bar' where it would normally search `/usr/local/lib/bar'.
- These alternate directories are searched first; the standard
- directories come next. 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 will use mblen and mbtowc as defined by the default
- locale to recognize and translate multibyte characters.
-
-Some additional environments 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::.
-
-\1f
-File: gcc.info, Node: Precompiled Headers, Next: Running Protoize, 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 users to
-`precompile' a header file; then, if builds can use the precompiled
-header file they will be much faster.
-
- 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 will probably 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 will be 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 will
-be used if possible, and the original header will be 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 will be 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 will
-be considered. The first precompiled header encountered in the
-directory that is valid for this compilation will be 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 can even include a precompiled header from inside another
- header, so long as there are no C tokens before the `#include'.
-
- * 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 will automatically
-ignore 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 will be 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.
-
-\1f
-File: gcc.info, Node: Running Protoize, Prev: Precompiled Headers, Up: Invoking GCC
-
-3.21 Running Protoize
-=====================
-
-The program `protoize' is an optional part of GCC. You can use it to
-add prototypes to a program, thus converting the program to ISO C in
-one respect. The companion program `unprotoize' does the reverse: it
-removes argument types from any prototypes that are found.
-
- When you run these programs, you must specify a set of source files as
-command line arguments. The conversion programs start out by compiling
-these files to see what functions they define. The information gathered
-about a file FOO is saved in a file named `FOO.X'.
-
- After scanning comes actual conversion. The specified files are all
-eligible to be converted; any files they include (whether sources or
-just headers) are eligible as well.
-
- But not all the eligible files are converted. By default, `protoize'
-and `unprotoize' convert only source and header files in the current
-directory. You can specify additional directories whose files should
-be converted with the `-d DIRECTORY' option. You can also specify
-particular files to exclude with the `-x FILE' option. A file is
-converted if it is eligible, its directory name matches one of the
-specified directory names, and its name within the directory has not
-been excluded.
-
- Basic conversion with `protoize' consists of rewriting most function
-definitions and function declarations to specify the types of the
-arguments. The only ones not rewritten are those for varargs functions.
-
- `protoize' optionally inserts prototype declarations at the beginning
-of the source file, to make them available for any calls that precede
-the function's definition. Or it can insert prototype declarations
-with block scope in the blocks where undeclared functions are called.
-
- Basic conversion with `unprotoize' consists of rewriting most function
-declarations to remove any argument types, and rewriting function
-definitions to the old-style pre-ISO form.
-
- Both conversion programs print a warning for any function declaration
-or definition that they can't convert. You can suppress these warnings
-with `-q'.
-
- The output from `protoize' or `unprotoize' replaces the original
-source file. The original file is renamed to a name ending with
-`.save' (for DOS, the saved filename ends in `.sav' without the
-original `.c' suffix). If the `.save' (`.sav' for DOS) file already
-exists, then the source file is simply discarded.
-
- `protoize' and `unprotoize' both depend on GCC itself to scan the
-program and collect information about the functions it uses. So
-neither of these programs will work until GCC is installed.
-
- Here is a table of the options you can use with `protoize' and
-`unprotoize'. Each option works with both programs unless otherwise
-stated.
-
-`-B DIRECTORY'
- Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the
- usual directory (normally `/usr/local/lib'). This file contains
- prototype information about standard system functions. This option
- applies only to `protoize'.
-
-`-c COMPILATION-OPTIONS'
- Use COMPILATION-OPTIONS as the options when running `gcc' to
- produce the `.X' files. The special option `-aux-info' is always
- passed in addition, to tell `gcc' to write a `.X' file.
-
- Note that the compilation options must be given as a single
- argument to `protoize' or `unprotoize'. If you want to specify
- several `gcc' options, you must quote the entire set of
- compilation options to make them a single word in the shell.
-
- There are certain `gcc' arguments that you cannot use, because they
- would produce the wrong kind of output. These include `-g', `-O',
- `-c', `-S', and `-o' If you include these in the
- COMPILATION-OPTIONS, they are ignored.
-
-`-C'
- Rename files to end in `.C' (`.cc' for DOS-based file systems)
- instead of `.c'. This is convenient if you are converting a C
- program to C++. This option applies only to `protoize'.
-
-`-g'
- Add explicit global declarations. This means inserting explicit
- declarations at the beginning of each source file for each function
- that is called in the file and was not declared. These
- declarations precede the first function definition that contains a
- call to an undeclared function. This option applies only to
- `protoize'.
-
-`-i STRING'
- Indent old-style parameter declarations with the string STRING.
- This option applies only to `protoize'.
-
- `unprotoize' converts prototyped function definitions to old-style
- function definitions, where the arguments are declared between the
- argument list and the initial `{'. By default, `unprotoize' uses
- five spaces as the indentation. If you want to indent with just
- one space instead, use `-i " "'.
-
-`-k'
- Keep the `.X' files. Normally, they are deleted after conversion
- is finished.
-
-`-l'
- Add explicit local declarations. `protoize' with `-l' inserts a
- prototype declaration for each function in each block which calls
- the function without any declaration. This option applies only to
- `protoize'.
-
-`-n'
- Make no real changes. This mode just prints information about the
- conversions that would have been done without `-n'.
-
-`-N'
- Make no `.save' files. The original files are simply deleted.
- Use this option with caution.
-
-`-p PROGRAM'
- Use the program PROGRAM as the compiler. Normally, the name `gcc'
- is used.
-
-`-q'
- Work quietly. Most warnings are suppressed.
-
-`-v'
- Print the version number, just like `-v' for `gcc'.
-
- If you need special compiler options to compile one of your program's
-source files, then you should generate that file's `.X' file specially,
-by running `gcc' on that source file with the appropriate options and
-the option `-aux-info'. Then run `protoize' on the entire set of
-files. `protoize' will use the existing `.X' file because it is newer
-than the source file. For example:
-
- gcc -Dfoo=bar file1.c -aux-info file1.X
- protoize *.c
-
-You need to include the special files along with the rest in the
-`protoize' command, even though their `.X' files already exist, because
-otherwise they won't get converted.
-
- *Note Protoize Caveats::, for more information on how to use
-`protoize' successfully.
-
-\1f
-File: gcc.info, Node: C Implementation, Next: C Extensions, 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 and ISO/IEC 9899:1999 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::
-
-\1f
-File: gcc.info, Node: Translation implementation, Next: Environment implementation, Up: C Implementation
-
-4.1 Translation
-===============
-
- * `How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99
- 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 and C99 5.1.1.2).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-
-\1f
-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 and C99
- 5.1.1.2).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-
-\1f
-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 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 and C99 5.2.4.1, C99 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 requires that case
- distinctions are always significant in identifiers with external
- linkage and systems without this property are not supported by GCC.
-
-
-\1f
-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 3.6).'
-
- Determined by ABI.
-
- * `The values of the members of the execution character set (C90 and
- C99 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
- and C99 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 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 6.2.5, C99 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 6.4.4.4, C90 and C99 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 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 containing a multibyte character or escape
- sequence not represented in the extended execution character set
- (C90 6.1.3.4, C99 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 6.4.4.4).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The current locale used to convert a wide string literal into
- corresponding wide character codes (C90 6.1.4, C99 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 6.4.5).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-\1f
-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
- 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 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 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 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 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 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 requirement that the result of division
- is truncated towards zero.
-
-
-\1f
-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 and C99 5.2.4.2.2).'
-
- The accuracy is unknown.
-
- * `The rounding behaviors characterized by non-standard values of
- `FLT_ROUNDS' (C90 and C99 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 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 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
- 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 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 6.5).'
-
- Expressions are currently only contracted if
- `-funsafe-math-optimizations' or `-ffast-math' are used. This is
- subject to change.
-
- * `The default state for the `FENV_ACCESS' pragma (C99 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 7.6,
- C99 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 7.12.2).'
-
- This pragma is not implemented. Expressions are currently only
- contracted if `-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.
-
-
-\1f
-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 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 6.5.6/8.
-
- * `The size of the result of subtracting two pointers to elements of
- the same array (C90 6.3.6, C99 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.
-
-\1f
-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 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 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.
-
-
-\1f
-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 6.7.2, C99 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 6.7.2.1).'
-
- No other types are permitted in strictly conforming mode.
-
- * `Whether a bit-field can straddle a storage-unit boundary (C90
- 6.5.2.1, C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The order of allocation of bit-fields within a unit (C90 6.5.2.1,
- C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The alignment of non-bit-field members of structures (C90
- 6.5.2.1, C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The integer type compatible with each enumerated type (C90
- 6.5.2.2, C99 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.
-
-
-\1f
-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 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.
-
-
-\1f
-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.
-
-
-\1f
-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.
-
-
-\1f
-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.
-
- * `How sequences in both forms of header names are mapped to headers
- or external source file names (C90 6.1.7, C99 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
- 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 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 6.10.2).'
-
- * `How the named source file is searched for in an included `""'
- delimited header (C90 6.8.2, C99 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 6.10.2).'
-
- * `The nesting limit for `#include' processing (C90 6.8.2, C99
- 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 6.10.3.2).'
-
- * `The behavior on each recognized non-`STDC #pragma' directive (C90
- 6.8.6, C99 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).'
-
-
-\1f
-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).'
-
- 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.
-
-
-\1f
-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 and C99
- 5.2.4.2, C99 7.18.2, C99 7.18.3).'
-
- Determined by ABI.
-
- * `The number, order, and encoding of bytes in any object (when not
- explicitly specified in this International Standard) (C99
- 6.2.6.1).'
-
- Determined by ABI.
-
- * `The value of the result of the `sizeof' operator (C90 6.3.3.4,
- C99 6.5.3.4).'
-
- Determined by ABI.
-
-
-\1f
-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.
-
-\1f
-File: gcc.info, Node: C Extensions, Next: C++ Extensions, Prev: C Implementation, Up: Top
-
-5 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 C89 or C++ are also, as
-extensions, accepted by GCC in C89 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.
-* Long Long:: Double-word integers---`long long int'.
-* Complex:: Data types for complex numbers.
-* Floating Types:: Additional Floating Types.
-* Decimal Float:: Decimal Floating Types.
-* Hex Floats:: Hexadecimal floating-point constants.
-* Fixed-Point:: Fixed-Point Types.
-* Zero Length:: Zero-length arrays.
-* Variable Length:: Arrays whose length is computed at run time.
-* Empty Structures:: Structures with no members.
-* 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.
-* Cast to Union:: Casting to union type from any member of the union.
-* Case Ranges:: `case 1 ... 9' and such.
-* 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).
-* 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'.
-* Atomic Builtins:: Built-in functions for atomic memory access.
-* Object Size Checking:: Built-in functions for limited buffer overflow
- checking.
-* 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.
-
-\1f
-File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions
-
-5.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' (*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 ()
-
-will construct a temporary `A' object to hold the result of the
-statement expression, and that will be used to invoke `Foo'. Therefore
-the `this' pointer observed by `Foo' will not be the address of `a'.
-
- Any temporaries created within a statement within a statement
-expression will be destroyed at the statement's end. This makes
-statement expressions inside macros slightly different from function
-calls. In the latter case temporaries introduced during argument
-evaluation will be destroyed at the end of the statement that includes
-the function call. In the statement expression case they will be
-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 ());
- }
-
-will have different places where temporaries are destroyed. For the
-`macro' case, the temporary `X' will be destroyed just after the
-initialization of `b'. In the `function' case that temporary will be
-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-expression 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::)
-yields 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();
-
-will call `foo' and `bar1' and will not call `baz' but may or may not
-call `bar2'. If `bar2' is called, it will be called after `foo' and
-before `bar1'
-
-\1f
-File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions
-
-5.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 was 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 will be 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.
-
-\1f
-File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions
-
-5.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
-will serve 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 will 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__))' should be
-used to prevent inlining. If `&&foo' is used in a static variable
-initializer, inlining 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.
-
-\1f
-File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions
-
-5.4 Nested Functions
-====================
-
-A "nested function" is a function defined inside another function.
-(Nested functions are not supported for 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 has exited, all hell will break loose. If you try
-to call it after a containing scope level has exited, 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". A paper describing them is available as
-
-`http://people.debian.org/~aaronl/Usenix88-lexic.pdf'.
-
- A nested function can jump to a label inherited from a containing
-function, provided the label was explicitly declared in the containing
-function (*note Local Labels::). Such a jump returns instantly to the
-containing function, exiting the nested function which 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];
- }
- /* ... */
- }
-
-\1f
-File: gcc.info, Node: Constructing Calls, Next: Typeof, Prev: Nested Functions, Up: C Extensions
-
-5.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 were 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 was 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 which
- will be 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: __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 which
- will be 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 will do link or runtime 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
-
-\1f
-File: gcc.info, Node: Typeof, Next: Conditionals, Prev: Constructing Calls, Up: C Extensions
-
-5.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 could be
-used. For example, you can use it in a declaration, in a cast, or
-inside of `sizeof' or `typeof'.
-
- `typeof' is often useful in conjunction with the
-statements-within-expressions feature. Here is how the two together can
-be used to define a safe "maximum" macro that 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'.
-
- _Compatibility Note:_ In addition to `typeof', GCC 2 supported a more
-limited extension which 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
-will crash; 3.2.1 and later give an error). Code which relies on it
-should be rewritten to use `typeof':
-
- typedef typeof(EXPR) T;
-
-This will work with all versions of GCC.
-
-\1f
-File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Typeof, Up: C Extensions
-
-5.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.
-
-\1f
-File: gcc.info, Node: Long Long, Next: Complex, Prev: Conditionals, Up: C Extensions
-
-5.8 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 C89 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 fullword-to-doubleword a 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, unless you declare function prototypes. If a function
-expects type `int' for its argument, and you pass a value of type `long
-long int', confusion will result because the caller and the subroutine
-will 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.
-
-\1f
-File: gcc.info, Node: Complex, Next: Floating Types, Prev: Long Long, Up: C Extensions
-
-5.9 Complex Numbers
-===================
-
-ISO C99 supports complex floating data types, and as an extension GCC
-supports them in C89 mode and in C++, and 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 GNU libc), 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 DWARF2
-debug info format can represent this, so use of DWARF2 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.
-
-\1f
-File: gcc.info, Node: Floating Types, Next: Decimal Float, Prev: Complex, Up: C Extensions
-
-5.10 Additional Floating Types
-==============================
-
-As an extension, the GNU C compiler supports additional floating types,
-`__float80' and `__float128' to support 80bit (`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 ia64 targets.
-
-\1f
-File: gcc.info, Node: Decimal Float, Next: Hex Floats, Prev: Floating Types, Up: C Extensions
-
-5.11 Decimal Floating Types
-===========================
-
-As an extension, the GNU C compiler 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:
-
- * Pragma `FLOAT_CONST_DECIMAL64' is not supported, nor is the `d'
- suffix for literal constants of type `double'.
-
- * 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 DWARF2 debug information format.
-
-\1f
-File: gcc.info, Node: Hex Floats, Next: Fixed-Point, Prev: Decimal Float, Up: C Extensions
-
-5.12 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 C89 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 will be 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'.
-
-\1f
-File: gcc.info, Node: Fixed-Point, Next: Zero Length, Prev: Hex Floats, Up: C Extensions
-
-5.13 Fixed-Point Types
-======================
-
-As an extension, the GNU C compiler 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 DWARF2 debug information format.
-
-\1f
-File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Fixed-Point, Up: C Extensions
-
-5.14 Arrays of Length Zero
-==========================
-
-Zero-length arrays are allowed in GNU C. They are very useful as the
-last element of a structure which 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.
-I.e. 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.
-
-\1f
-File: gcc.info, Node: Empty Structures, Next: Variadic Macros, Prev: Variable Length, Up: C Extensions
-
-5.15 Structures With No Members
-===============================
-
-GCC permits a C structure to have no members:
-
- struct empty {
- };
-
- The structure will have 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'.
-
-\1f
-File: gcc.info, Node: Variable Length, Next: Empty Structures, Prev: Zero Length, Up: C Extensions
-
-5.16 Arrays of Variable Length
-==============================
-
-Variable-length automatic arrays are allowed in ISO C99, and as an
-extension GCC accepts them in C89 mode and in C++. (However, GCC's
-implementation of variable-length arrays does not yet conform in detail
-to the ISO C99 standard.) 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 brace-level is exited. 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.
-
- 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
-will also deallocate 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.
-
-\1f
-File: gcc.info, Node: Variadic Macros, Next: Escaped Newlines, Prev: Empty Structures, Up: C Extensions
-
-5.17 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.
-
-\1f
-File: gcc.info, Node: Escaped Newlines, Next: Subscripting, Prev: Variadic Macros, Up: C Extensions
-
-5.18 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.
-
-\1f
-File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Escaped Newlines, Up: C Extensions
-
-5.19 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, GCC allows such arrays to be subscripted in C89
-mode, though otherwise they do not decay to pointers outside C99 mode.
-For example, this is valid in GNU C though not valid in C89:
-
- struct foo {int a[4];};
-
- struct foo f();
-
- bar (int index)
- {
- return f().a[index];
- }
-
-\1f
-File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: C Extensions
-
-5.20 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.
-
-\1f
-File: gcc.info, Node: Initializers, Next: Compound Literals, Prev: Pointer Arith, Up: C Extensions
-
-5.21 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 };
- /* ... */
- }
-
-\1f
-File: gcc.info, Node: Compound Literals, Next: Designated Inits, Prev: Initializers, Up: C Extensions
-
-5.22 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 C89 mode and 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. 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 is 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 was 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};
-
-\1f
-File: gcc.info, Node: Designated Inits, Next: Cast to Union, Prev: Compound Literals, Up: C Extensions
-
-5.23 Designated Initializers
-============================
-
-Standard C89 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 C89 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 which 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 will 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 which has the same meaning, obsolete since GCC 2.5, is
-`FIELDNAME:', as shown here:
-
- struct point p = { y: yvalue, x: xvalue };
-
- 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 };
-
-will convert 4 to a `double' to store it in the union using the second
-element. By contrast, casting 4 to type `union foo' would store 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 will have 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 will discard them and issue a warning.
-
-\1f
-File: gcc.info, Node: Case Ranges, Next: Mixed Declarations, Prev: Cast to Union, Up: C Extensions
-
-5.24 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:
-
-\1f
-File: gcc.info, Node: Cast to Union, Next: Case Ranges, Prev: Designated Inits, Up: C Extensions
-
-5.25 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
-though, 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);
-
-\1f
-File: gcc.info, Node: Mixed Declarations, Next: Function Attributes, Prev: Case Ranges, Up: C Extensions
-
-5.26 Mixed Declarations and Code
-================================
-
-ISO C99 and ISO C++ allow declarations and code to be freely mixed
-within compound statements. As an extension, GCC also allows this in
-C89 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.
-
-\1f
-File: gcc.info, Node: Function Attributes, Next: Attribute Syntax, Prev: Mixed Declarations, Up: C Extensions
-
-5.27 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', `noreturn', `returns_twice', `noinline', `always_inline',
-`flatten', `pure', `const', `nothrow', `sentinel', `format',
-`format_arg', `no_instrument_function', `section', `constructor',
-`destructor', `used', `unused', `deprecated', `weak', `malloc',
-`alias', `warn_unused_result', `nonnull', `gnu_inline',
-`externally_visible', `hot', `cold', `artificial', `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::).
-
- 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 will override 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 will return memory of the size given by
- the product of parameter 1 and 2 and that my_realloc will return
- memory of the size given by parameter 2.
-
-`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 was specified.
-
-`gnu_inline'
- This attribute should be used with a function which is also
- declared with the `inline' keyword. It directs GCC to treat the
- function as if it were defined in gnu89 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 will cause most calls to the
- function to be inlined. If any uses of the function remain, they
- will 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 which if
- possible should appear during debugging as a unit, depending on
- the debug info format it will either mean marking the function as
- artificial or using the caller location for all instructions
- within the inlined body.
-
-`flatten'
- Generally, inlining into a function is limited. For a function
- marked with this attribute, every call inside this function will
- be 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 which will include MESSAGE will be
- 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 will be 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 which will include MESSAGE will be
- 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
- will be 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 will pop 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 ()' has completed or `exit ()' has been
- called. Functions with these attributes are useful for
- initializing data that will be 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'
- 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 `deprecated' attribute can also be used for variables and
- types (*note Variable Attributes::, *note Type Attributes::.)
-
-`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.
-
- Currently, the `dllexport' attribute is ignored for inlined
- functions, unless the `-fkeep-inline-functions' flag has been
- used. 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 dllimport'ed constructor or a non-inline, non-pure
- virtual function and, for either of those two conditions, the
- class also has a inline constructor or destructor and has a key
- function that is defined in the current translation unit.
-
- For Microsoft Windows based 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 will generate 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_handler'
- Use this attribute on the Blackfin to indicate that the specified
- function is an exception handler. The compiler will generate
- 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.
-
-`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 will use the `call' and `rtc' instructions
- to call and return from a function.
-
- On 68HC11 the compiler will generate 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 will jump to a board-specific routine
- instead of using `rts'. The board-specific return routine
- simulates the `rtc'.
-
-`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 will pop the arguments off the stack. If the
- number of arguments is variable all arguments are pushed on the
- stack.
-
-`format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
- The `format' attribute specifies that a function takes `printf',
- `scanf', `strftime' or `strfmon' style arguments which 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. ARCHTYPE values such as `printf'
- refer to the formats accepted by the system's C run-time library,
- while `gnu_' values always refer to the formats accepted by the
- GNU C Library. On Microsoft Windows targets, `ms_' values 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
- which 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.
-
- The target may 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 which 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.
-
-`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 will
- reduce 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.
-
- In SH2A target, 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
- the successful jump, register TBR should contain the start address
- of this TBR relative vector table. In the startup routine of the
- user application, user needs to care of this TBR register
- initialization. The TBR relative vector table can have at max 256
- function entries. The jumps to these functions will be 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 will save at least 8 bytes of code; and if other
- successive calls are being made to the same function, it will save
- 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) which are used in `jsrs'
- instruction. 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 will be 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.
-
-`interrupt'
- Use this attribute on the ARM, AVR, CRX, M32C, M32R/D, m68k, and
- Xstormy16 ports to indicate that the specified function is an
- interrupt handler. The compiler will generate function entry and
- exit sequences suitable for use in an interrupt handler when this
- attribute is present.
-
- Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S,
- and SH processors can be specified via the `interrupt_handler'
- attribute.
-
- Note, on the AVR, interrupts will be enabled inside the function.
-
- 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.
-
-`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 will generate 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 will be 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 will be put into a specific section
- named `.l1.text'. With `-mfdpic', function calls with a such
- function as the callee or caller will use inlined PLT.
-
-`long_call/short_call'
- This attribute specifies how a particular function is called on
- ARM. Both attributes override the `-mlong-calls' (*note ARM
- Options::) command line switch and `#pragma long_calls' settings.
- 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.
-
-`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. This
- will often improve optimization. Standard functions with this
- property include `malloc' and `calloc'. `realloc'-like functions
- have this property as long as the old pointer is never referred to
- (including comparing it to the new pointer) after the function
- returns a non-`NULL' value.
-
-`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::).
-
-`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 will generate `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 will generate `seth/add3' instructions to load their
- addresses), and may not be reachable with the `bl' instruction
- (the compiler will generate 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 64-bit 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 AMD ABI.
-
- Note, This feature is currently sorried out for Windows targets
- trying to
-
-`naked'
- Use this attribute on the ARM, AVR, IP2K 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.
-
-`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 will generate function
- entry and exit sequences suitable for use in an NMI handler when
- this attribute is present.
-
-`no_instrument_function'
- If `-finstrument-functions' is given, profiling function calls will
- be generated at entry and exit of most user-compiled functions.
- Functions with this attribute will not be so instrumented.
-
-`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 causes 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.
-
-`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 not 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));
-
-`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.
-
-`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 called with
- less aggressive options.
-
-`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 is used to inform the compiler that a 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 is not implemented in GCC versions earlier
- than 4.3.
-
-`cold'
- The `cold' attribute is used to inform the compiler that a
- function is unlikely 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', hot
- functions are automatically detected and this attribute is ignored.
-
- The `cold' attribute is not implemented in GCC versions earlier
- than 4.3.
-
-`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 will 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 will send 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. GNU systems with GLIBC 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.)
-
-`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 will 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 runtime 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.
-
-`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 will ensure that all
- registers are dead before calling such a function and will emit 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.
-
-`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 a signal handler. The compiler will generate function
- entry and exit sequences suitable for use in a signal handler when
- this attribute is present. Interrupts will be disabled inside the
- function.
-
-`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 will pop 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 IA64 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")' that would be 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 was 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")));
-
- 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.
-
- `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.
-
- `sse5'
- `no-sse5'
- Enable/disable the generation of the SSE5 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 386, you can use either multiple strings to specify multiple
- options, or you can separate the option with a comma (`,').
-
- On the 386, the inliner will 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("sse5")' can inline a function with
- `target("sse2")', since `-msse5' implies `-msse2'.
-
- The `target' attribute is not implemented in GCC versions earlier
- than 4.4, and at present only the 386 uses it.
-
-`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 will generate more efficient code for loads and stores
- on data in the tiny data section. Note the tiny data area is
- limited to slightly under 32kbytes 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.
-
-`unused'
- This attribute, attached to a function, means that the function is
- meant to be possibly unused. GCC will 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.
-
-`version_id'
- This IA64 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 version level functioning for some system calls.
-
- extern int foo () __attribute__((version_id ("20040821")));
-
- Calls to FOO will be 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 will
- have a new form of linkage, which we'll 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 will
- 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
- which 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.
- 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.
-
-`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 which 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 the
- becomes a `weak' undefined symbol. If it is directly referenced,
- however, then such strong references prevail, and a definition
- will be 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 Miscellaneous Preprocessing Directives: (cpp)Other
-Directives.
-
-\1f
-File: gcc.info, Node: Attribute Syntax, Next: Function Prototypes, Prev: Function Attributes, Up: C Extensions
-
-5.28 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 code generated by programs which contains labels
-that may be unused but which is compiled with `-Wall'. It would not
-normally be 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++ does not permit such
-placement of attribute lists, 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 which 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 will make 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 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 will be 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 will be 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 will be treated as
-applying to the function type, and such an attribute applied to an array
-element type will be 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 will be 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 will be treated as applying
-to the function type.
-
-\1f
-File: gcc.info, Node: Function Prototypes, Next: C++ Comments, Prev: Attribute Syntax, Up: C Extensions
-
-5.29 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.
-
-\1f
-File: gcc.info, Node: C++ Comments, Next: Dollar Signs, Prev: Function Prototypes, Up: C Extensions
-
-5.30 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=c89').
-
-\1f
-File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: C++ Comments, Up: C Extensions
-
-5.31 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.
-
-\1f
-File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: C Extensions
-
-5.32 The Character <ESC> in Constants
-=====================================
-
-You can use the sequence `\e' in a string or character constant to
-stand for the ASCII character <ESC>.
-
-\1f
-File: gcc.info, Node: Alignment, Next: Inline, Prev: Type Attributes, Up: C Extensions
-
-5.33 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 will give 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.
-
-\1f
-File: gcc.info, Node: Variable Attributes, Next: Type Attributes, Prev: Character Escapes, Up: C Extensions
-
-5.34 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
- that 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
- which 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 will
- generate 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__' will still
- only provide 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 will be 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'
- 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 `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 will change
- 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 will not produce a warning for
- this variable.
-
-`used'
- This attribute, attached to a variable, means that the variable
- must be emitted even if it appears that the variable is not
- referenced.
-
-`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' will be 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::.
-
-
-5.34.1 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 will be put into
- the specific section named `.l1.data'. Those with `l1_data_A'
- attribute will be put into the specific section named
- `.l1.data.A'. Those with `l1_data_B' attribute will be put into
- the specific section named `.l1.data.B'.
-
-5.34.2 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 will generate `seth/add3' instructions
- to load their addresses).
-
-5.34.3 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 packs them differently than GCC
- would normally pack 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.
-
- The Microsoft structure layout algorithm is fairly simple with the
- exception of the bitfield packing:
-
- The padding and alignment of members of structures and whether a
- bit field can straddle a storage-unit boundary
-
- 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.
-
- Handling of zero-length bitfields:
-
- MSVC interprets zero-length bitfields in the following ways:
-
- 1. If a zero-length bitfield is inserted between two bitfields
- that would normally be coalesced, the bitfields will not be
- coalesced.
-
- For example:
-
- struct
- {
- unsigned long bf_1 : 12;
- unsigned long : 0;
- unsigned long bf_2 : 12;
- } t1;
-
- The size of `t1' would be 8 bytes with the zero-length
- bitfield. If the zero-length bitfield were removed, `t1''s
- size would be 4 bytes.
-
- 2. If a zero-length bitfield is inserted after a bitfield,
- `foo', and the alignment of the zero-length bitfield is
- greater than the member that follows it, `bar', `bar' will be
- aligned as the type of the zero-length bitfield.
-
- For example:
-
- struct
- {
- char foo : 4;
- short : 0;
- char bar;
- } t2;
-
- struct
- {
- char foo : 4;
- short : 0;
- double bar;
- } t3;
-
- For `t2', `bar' will be placed at offset 2, rather than
- offset 1. Accordingly, the size of `t2' will be 4. For
- `t3', the zero-length bitfield will 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 bitfield follows a normal bitfield, the
- type of the zero-length bitfield may affect the
- alignment of the structure as whole. For example, `t2'
- has a size of 4 bytes, since the zero-length bitfield
- follows a normal bitfield, and is of type short.
-
- 2. Even if a zero-length bitfield is not followed by a
- normal bitfield, it may still affect the alignment of
- the structure:
-
- struct
- {
- char foo : 6;
- long : 0;
- } t4;
-
- Here, `t4' will take up 4 bytes.
-
- 3. Zero-length bitfields following non-bitfield members are
- ignored:
-
- struct
- {
- char foo;
- long : 0;
- char bar;
- } t5;
-
- Here, `t5' will take up 2 bytes.
-
-5.34.4 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::.
-
-5.34.5 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::.
-
-5.34.6 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 will place the variable in the first 0x100 bytes of
- memory and use special opcodes to access it. Such variables will
- be placed in either the `.bss_below100' section or the
- `.data_below100' section.
-
-
-5.34.7 AVR Variable Attributes
-------------------------------
-
-`progmem'
- The `progmem' attribute is used on the AVR to place data in the
- Program Memory address space. The AVR is a Harvard Architecture
- processor and data normally resides in the Data Memory address
- space.
-
-\1f
-File: gcc.info, Node: Type Attributes, Next: Alignment, Prev: Variable Attributes, Up: C Extensions
-
-5.35 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 insure (as far as it can) that each variable
- whose type is `struct S' or `more_aligned_int' will be 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 which 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 which
- 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 which 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 will also be doing 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 will often be 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__' will still
- only provide 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 bitfields) 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' would need
- 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 a `enum',
- `struct' or `union', not on a `typedef' which 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 will 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'
- 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 `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
- 6.5/7 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 will be unable to
- use the same typeinfo node and exception handling will break.
-
-
-5.35.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'.)
-
-5.35.2 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
- would normally pack 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.
-
- To specify multiple attributes, separate them by commas within the
-double parentheses: for example, `__attribute__ ((aligned (16),
-packed))'.
-
-5.35.3 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.
-
-5.35.4 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.
-
-\1f
-File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: C Extensions
-
-5.36 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' or `-std=gnu99' (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)
- {
- (*a)++;
- }
-
- If you are writing a header file to be included in ISO C89 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)
- {
- (*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: use of
-varargs, use of alloca, use of variable sized 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' will warn when a function marked `inline' could not be
-substituted, and will give 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 C89 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 will cause most calls to the function to be inlined.
-If any uses of the function remain, they will refer to the single copy
-in the library.
-
-\1f
-File: gcc.info, Node: Extended Asm, Next: Constraints, Prev: Inline, Up: C Extensions
-
-5.37 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 will 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
-will use the register as the output of the `asm', and then store that
-register into the output.
-
- The ordinary output operands must be write-only; GCC will assume 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 should only use read-write
-operands when the constraints for the operand (or the operand in which
-only some of the bits are to be changed) allow a register.
-
- 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 which 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 will be
-in the same place as another. The mere fact that `foo' is the value of
-both operands is not enough to guarantee that they will be in the same
-place in the generated assembler code. The following would 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 will
-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 will 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 will
-cause GCC to not keep memory values cached in registers across the
-assembler instruction and not optimize stores or loads to that memory.
-You will also want to 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" (r) : "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 will 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.
-
- 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' which 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 were `int', casting the argument to `int'
-would accept a pointer with no complaint, while assigning the argument
-to an `int' variable named `__arg' would warn 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 will not delete a volatile `asm' if it is reachable.
-(The instruction can still be deleted if GCC can prove that
-control-flow will never reach 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 which 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 will 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 will perform 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 will be 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 would result in
-additional following "store" instructions. On most machines, these
-instructions would alter the condition code before there was 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.
-
- If you are writing a header file that should be includable in ISO C
-programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::.
-
-5.37.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 would be needed for a single instruction.
-If this happens then the assembler will produce a diagnostic saying that
-a label is unreachable.
-
-5.37.2 i386 floating point asm operands
----------------------------------------
-
-There are several rules on the usage of stack-like regs in asm_operands
-insns. These rules apply only to the operands that are stack-like regs:
-
- 1. Given a set of input regs that die in an asm_operands, it is
- necessary to know which are implicitly popped by the asm, and
- which must be explicitly popped by gcc.
-
- An input reg that is implicitly popped by the asm must be
- explicitly clobbered, unless it is constrained to match an output
- operand.
-
- 2. For any input reg 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 reg, 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 regs 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 insn, reload might use
- the input reg for an output reload. Consider this example:
-
- asm ("foo" : "=t" (a) : "f" (b));
-
- This asm 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 will think that it can use the same reg for both the input
- and the output, if input B dies in this insn.
-
- If any input operand uses the `f' constraint, all output reg
- constraints must use the `&' earlyclobber.
-
- The asm above would be 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--there is no other way to
- know which regs the outputs appear in unless the user indicates
- this in the constraints.
-
- Output operands must specifically indicate which reg an output
- appears in after an asm. `=f' is not allowed: the operand
- constraints must select a class with a single reg.
-
- 4. Output operands may not be "inserted" between existing stack regs.
- Since no 387 opcode uses a read/write operand, all output operands
- are dead before the asm_operands, and are pushed by the
- asm_operands. 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 reg.
-
- 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 asms 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 user must code the `st(1)'
-clobber for reg-stack.c to know that `fyl2xp1' pops both inputs.
-
- asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
-
-\1f
-File: gcc.info, Node: Constraints, Next: Asm Labels, Prev: Extended Asm, Up: C Extensions
-
-5.38 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.
-
-* 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.
-
-\1f
-File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
-
-5.38.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.
-
-`>'
- A memory operand with autoincrement addressing (either
- preincrement or postincrement) is allowed.
-
-`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.
-
-\1f
-File: gcc.info, Node: Multi-Alternative, Next: Modifiers, Prev: Simple Constraints, Up: Constraints
-
-5.38.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.
-
-\1f
-File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Multi-Alternative, Up: Constraints
-
-5.38.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.
-
-
-\1f
-File: gcc.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints
-
-5.38.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.
-
-_ARM family--`config/arm/arm.h'_
-
- `f'
- Floating-point register
-
- `w'
- VFP floating-point register
-
- `F'
- One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
- 4.0, 5.0 or 10.0
-
- `G'
- Floating-point constant that would satisfy the constraint `F'
- if it were negated
-
- `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
-
- `R'
- Integer constant in the range -6 ... 5.
-
- `Q'
- A memory address based on Y or Z pointer with displacement.
-
-_CRX Architecture--`config/crx/crx.h'_
-
- `b'
- Registers from r0 to r14 (registers without stack pointer)
-
- `l'
- Register r16 (64-bit accumulator lo register)
-
- `h'
- Register r17 (64-bit accumulator hi register)
-
- `k'
- Register pair r16-r17. (64-bit accumulator lo-hi pair)
-
- `I'
- Constant that fits in 3 bits
-
- `J'
- Constant that fits in 4 bits
-
- `K'
- Constant that fits in 5 bits
-
- `L'
- Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
-
- `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/rs6000.h'_
-
- `b'
- Address base register
-
- `f'
- Floating point register
-
- `v'
- Vector register
-
- `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'
- `FPMEM' stack memory for FPR-GPR transfers
-
- `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
-
- `Q'
- Memory operand that is an offset from a register (`m' is
- preferable for `asm' statements)
-
- `Z'
- Memory operand that is an indexed or indirect from a register
- (`m' is preferable for `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
-
-
-_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, as a pair (for instructions that
- return half the result in one and half in the other).
-
- `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. Remember that `m' allows postincrement and
- postdecrement which require printing with `%Pn' on IA-64.
- Use `S' to disallow postincrement and postdecrement.
-
- `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
-
-_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
-
-_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.
-
-_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
-
-
-_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_
-
- `a'
- Register `a'
-
- `b'
- Register `b'
-
- `d'
- Register `d'
-
- `q'
- An 8-bit register
-
- `t'
- Temporary soft register _.tmp
-
- `u'
- A soft register _.d1 to _.d31
-
- `w'
- Stack pointer register
-
- `x'
- Register `x'
-
- `y'
- Register `y'
-
- `z'
- Pseudo register `z' (replaced by `x' or `y' at the end)
-
- `A'
- An address register: x, y or z
-
- `B'
- An address register: x or y
-
- `D'
- Register pair (x:d) to form a 32-bit value
-
- `L'
- Constants in the range -65536 to 65535
-
- `M'
- Constants whose 16-bit low part is zero
-
- `N'
- Constant integer 1 or -1
-
- `O'
- Constant integer 16
-
- `P'
- Constants in the range -8 to 2
-
-
-_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.
-
- `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
-
- `M'
- A constant in the range supported by `movrcc' instructions
-
- `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
-
- `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
-
- `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.
-
-
-_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
-
-
-
-\1f
-File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Constraints, Up: C Extensions
-
-5.39 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.
-
-\1f
-File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions
-
-5.40 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 which 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 will work provided the register you
- specify fits the constraints specified for that operand in the
- `asm'.)
-
-* Menu:
-
-* Global Reg Vars::
-* Local Reg Vars::
-
-\1f
-File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars
-
-5.40.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 which should be used. Choose a
-register which 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 would need to
-conditionalize your program according to cpu type. The register `a5'
-would be 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, operating systems on one type of cpu may differ in how
-they name the registers; then you would 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 will not be allocated for any other purpose in the
-functions in the current compilation. The register will not be saved
-and restored by these functions. Stores into this register are never
-deleted even if they would 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
-was compiled without knowledge of this variable (i.e. in a different
-source file in which the variable wasn'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 which do not
-actually use your global register variable, so that they will 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 which 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 which is the entry point into the part
-of the program that uses the global register variable must explicitly
-save and restore the value which belongs to its caller.
-
- On most machines, `longjmp' will restore to each global register
-variable the value it had at the time of the `setjmp'. On some
-machines, however, `longjmp' will 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 will happen 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 will not do to use more than a few of those.
-
-\1f
-File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars
-
-5.40.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 which should be used. Note that
-this is the same syntax used for defining global register variables,
-but for a local variable it would appear 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 would 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 will generate 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 will
-always refer 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 which 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 will overwrite 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::.
-
-\1f
-File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions
-
-5.41 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'). 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') 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.
-
-\1f
-File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions
-
-5.42 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
-which 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++.
-
-\1f
-File: gcc.info, Node: Function Names, Next: Return Address, Prev: Incomplete Enums, Up: C Extensions
-
-5.43 Function Names as Strings
-==============================
-
-GCC provides three magic variables which 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.
-
-\1f
-File: gcc.info, Node: Return Address, Next: Vector Extensions, Prev: Function Names, Up: C Extensions
-
-5.44 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 will return
- the address of the function that will be 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 will
- return `0' or a random value. In addition,
- `__builtin_frame_address' may be used to determine if the top of
- the stack has been reached.
-
- This function should only be used with a nonzero argument for
- debugging purposes.
-
- -- 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 which 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' will return 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 will
- return `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.
-
-\1f
-File: gcc.info, Node: Vector Extensions, Next: Offsetof, Prev: Return Address, Up: C Extensions
-
-5.45 Using vector instructions through built-in functions
-=========================================================
-
-On some targets, the instruction set contains SIMD vector instructions
-that 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' will be 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.
-
- 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
-will cause 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 will
-produce code that uses 4 `SIs'.
-
- The types defined in this manner can be used with a subset of normal C
-operations. Currently, GCC will allow 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 will be added
-to the corresponding 4 elements in B and the resulting vector will be
-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.
-
- 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.
-
- A port that supports hardware vector operations, usually provides a set
-of built-in functions that can be used to operate on vectors. For
-example, a function to add two vectors and multiply the result by a
-third could look like this:
-
- v4si f (v4si a, v4si b, v4si c)
- {
- v4si tmp = __builtin_addv4si (a, b);
- return __builtin_mulv4si (tmp, c);
- }
-
-\1f
-File: gcc.info, Node: Offsetof, Next: Atomic Builtins, Prev: Vector Extensions, Up: C Extensions
-
-5.46 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.
-
-\1f
-File: gcc.info, Node: Atomic Builtins, Next: Object Size Checking, Prev: Offsetof, Up: C Extensions
-
-5.47 Built-in functions for atomic memory access
-================================================
-
-The following builtins 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 will allow 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 will be generated and a call an external function will be
-generated. The external function will carry the same name as the
-builtin, with an additional suffix `_N' where N is the size of the data
-type.
-
- In most cases, these builtins are considered a "full barrier". That
-is, no memory operand will be moved across the operation, either
-forward or backward. Further, instructions will be 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 which 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 builtins 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'
- builtin 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 builtins 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'
- builtin 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 builtins 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 was written. The "val" version returns the contents of
- `*PTR' before the operation.
-
-`__sync_synchronize (...)'
- This builtin issues a full memory barrier.
-
-`TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)'
- This builtin, 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 builtin is not a full barrier, but rather an "acquire
- barrier". This means that references after the builtin cannot
- move to (or be speculated to) before the builtin, 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 builtin releases the lock acquired by
- `__sync_lock_test_and_set'. Normally this means writing the
- constant 0 to `*PTR'.
-
- This builtin 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.
-
-\1f
-File: gcc.info, Node: Object Size Checking, Next: Other Builtins, Prev: Atomic Builtins, Up: C Extensions
-
-5.48 Object Size Checking Builtins
-==================================
-
-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 runtime. */
- 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 runtime. */
- 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
-will, otherwise the checking function should be called and the FLAG
-argument passed to it.
-
-\1f
-File: gcc.info, Node: Other Builtins, Next: Target Builtins, Prev: Object Size Checking, Up: C Extensions
-
-5.49 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 will not be
-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_' will always be
-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 will be
-emitted.
-
- Outside strict ISO C mode (`-ansi', `-std=c89' or `-std=c99'), 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 C89 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=c89').
-
- 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=c89').
-
- 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' builtins 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 would 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 a
- constant expression that must be able to be determined at compile
- time, is nonzero. Otherwise it returns 0.
-
- 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 was 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: 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 would typically use this function in an embedded application
- where memory was 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
- will never return 1 when you call the inline function with a
- string constant or compound literal (*note Compound Literals::)
- and will 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. 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 ();
-
- would indicate 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))
- error ();
-
- 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___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 will be 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' will not fault if `p->next' is not a valid address,
- but evaluation will fault 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 will be negative 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 (unsigned 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_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 (unsigned long)
- Similar to `__builtin_ffs', except the argument type is `unsigned
- 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_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 (unsigned long long)
- Similar to `__builtin_ffs', except the argument type is `unsigned
- 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_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: int32_t __builtin_bswap32 (int32_t x)
- Returns X with the order of the bytes reversed; for example,
- `0xaabbccdd' becomes `0xddccbbaa'. Byte here always means exactly
- 8 bits.
-
- -- Built-in Function: int64_t __builtin_bswap64 (int64_t x)
- Similar to `__builtin_bswap32', except the argument and return
- types are 64-bit.
-
-\1f
-File: gcc.info, Node: Target Builtins, Next: Target Format Checks, Prev: Other Builtins, Up: C Extensions
-
-5.50 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::
-* ARM iWMMXt Built-in Functions::
-* ARM NEON Intrinsics::
-* Blackfin Built-in Functions::
-* FR-V Built-in Functions::
-* X86 Built-in Functions::
-* MIPS DSP Built-in Functions::
-* MIPS Paired-Single Support::
-* MIPS Loongson Built-in Functions::
-* Other MIPS Built-in Functions::
-* picoChip Built-in Functions::
-* PowerPC AltiVec Built-in Functions::
-* SPARC VIS Built-in Functions::
-* SPU Built-in Functions::
-
-\1f
-File: gcc.info, Node: Alpha Built-in Functions, Next: ARM iWMMXt Built-in Functions, Up: Target Builtins
-
-5.50.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 builtins 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 *)
-
-\1f
-File: gcc.info, Node: ARM iWMMXt Built-in Functions, Next: ARM NEON Intrinsics, Prev: Alpha Built-in Functions, Up: Target Builtins
-
-5.50.2 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_getwcx (int)
- void __builtin_arm_setwcx (int, 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)
- v4hi __builtin_arm_tinsrh (v4hi, int)
- v2si __builtin_arm_tinsrw (v2si, 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 (v8qi, v8qi)
- v2si __builtin_arm_wsadbz (v8qi, v8qi)
- v2si __builtin_arm_wsadh (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 ()
-
-\1f
-File: gcc.info, Node: ARM NEON Intrinsics, Next: Blackfin Built-in Functions, Prev: ARM iWMMXt Built-in Functions, Up: Target Builtins
-
-5.50.3 ARM NEON Intrinsics
---------------------------
-
-These built-in intrinsics for the ARM Advanced SIMD extension are
-available when the `-mfpu=neon' switch is used:
-
-5.50.3.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'
-
- * uint64x1_t vadd_u64 (uint64x1_t, uint64x1_t)
- _Form of expected instruction(s):_ `vadd.i64 D0, D0, D0'
-
- * int64x1_t vadd_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vadd.i64 D0, D0, D0'
-
- * float32x2_t vadd_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vadd.f32 D0, D0, D0'
-
- * 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'
-
-5.50.3.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'
-
-5.50.3.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'
-
-5.50.3.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'
-
-5.50.3.5 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'
-
- * uint64x1_t vsub_u64 (uint64x1_t, uint64x1_t)
- _Form of expected instruction(s):_ `vsub.i64 D0, D0, D0'
-
- * int64x1_t vsub_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vsub.i64 D0, D0, D0'
-
- * float32x2_t vsub_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vsub.f32 D0, D0, D0'
-
- * 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'
-
-5.50.3.6 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'
-
-5.50.3.7 Comparison (greater-than-or-equal-to)
-..............................................
-
- * 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'
-
- * 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'
-
- * 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'
-
- * 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'
-
-5.50.3.8 Comparison (less-than-or-equal-to)
-...........................................
-
- * 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'
-
- * 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'
-
- * 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'
-
- * 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'
-
-5.50.3.9 Comparison (greater-than)
-..................................
-
- * 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'
-
- * 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'
-
- * 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'
-
- * 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'
-
-5.50.3.10 Comparison (less-than)
-................................
-
- * 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'
-
- * 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'
-
- * 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'
-
- * 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'
-
-5.50.3.11 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'
-
-5.50.3.12 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'
-
-5.50.3.13 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'
-
-5.50.3.14 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'
-
-5.50.3.15 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'
-
-5.50.3.16 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'
-
-5.50.3.17 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'
-
-5.50.3.18 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'
-
-5.50.3.19 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'
-
-5.50.3.20 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'
-
-5.50.3.21 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'
-
-5.50.3.22 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'
-
-5.50.3.23 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'
-
-5.50.3.24 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'
-
-5.50.3.25 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'
-
-5.50.3.26 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'
-
-5.50.3.27 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'
-
-5.50.3.28 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'
-
-5.50.3.29 Vector shift right and insert
-.......................................
-
- * 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'
-
- * 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'
-
-5.50.3.30 Vector shift left and insert
-......................................
-
- * 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'
-
- * 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'
-
-5.50.3.31 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'
-
-5.50.3.32 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'
-
-5.50.3.33 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'
-
-5.50.3.34 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'
-
-5.50.3.35 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'
-
-5.50.3.36 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'
-
-5.50.3.37 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'
-
-5.50.3.38 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'
-
-5.50.3.39 Get lanes from a vector
-.................................
-
- * uint32_t vget_lane_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.u32 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.s32 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.f32 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)
- _Form of expected instruction(s):_ `vmov R0, R0, D0'
-
- * int64_t vget_lane_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vmov R0, R0, D0'
-
- * uint32_t vgetq_lane_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.u32 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.s32 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.f32 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'
-
- * int64_t vgetq_lane_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vmov R0, R0, D0'
-
-5.50.3.40 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)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x1_t vset_lane_s64 (int64_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * 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'
-
-5.50.3.41 Create vector from literal bit pattern
-................................................
-
- * 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)
-
-5.50.3.42 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'
-
- * uint64x1_t vdup_n_u64 (uint64_t)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x1_t vdup_n_s64 (int64_t)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * 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)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x2_t vdupq_n_s64 (int64_t)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * 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)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x1_t vmov_n_s64 (int64_t)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * 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)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x2_t vmovq_n_s64 (int64_t)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * 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]'
-
- * 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]'
-
- * uint64x2_t vdupq_lane_u64 (uint64x1_t, const int)
-
- * int64x2_t vdupq_lane_s64 (int64x1_t, const int)
-
-5.50.3.43 Combining vectors
-...........................
-
- * 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)
-
-5.50.3.44 Splitting vectors
-...........................
-
- * 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'
-
- * uint64x1_t vget_low_u64 (uint64x2_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * int64x1_t vget_low_s64 (int64x2_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'
-
-5.50.3.45 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'
-
- * 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'
-
-5.50.3.46 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'
-
-5.50.3.47 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'
-
-5.50.3.48 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'
-
-5.50.3.49 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'
-
-5.50.3.50 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]'
-
-5.50.3.51 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]'
-
-5.50.3.52 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]'
-
-5.50.3.53 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]'
-
-5.50.3.54 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]'
-
-5.50.3.55 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]'
-
-5.50.3.56 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]'
-
-5.50.3.57 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]'
-
-5.50.3.58 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]'
-
-5.50.3.59 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]'
-
-5.50.3.60 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]'
-
-5.50.3.61 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]'
-
-5.50.3.62 Vector extract
-........................
-
- * 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'
-
- * 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'
-
-5.50.3.63 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'
-
-5.50.3.64 Bit selection
-.......................
-
- * 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'
-
- * 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'
-
-5.50.3.65 Transpose elements
-............................
-
- * uint32x2x2_t vtrn_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 D0, D1'
-
- * 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'
-
- * int32x2x2_t vtrn_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 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'
-
- * float32x2x2_t vtrn_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 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'
-
- * 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'
-
-5.50.3.66 Zip elements
-......................
-
- * uint32x2x2_t vzip_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vzip.32 D0, D1'
-
- * 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'
-
- * int32x2x2_t vzip_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vzip.32 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'
-
- * float32x2x2_t vzip_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vzip.32 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'
-
- * 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'
-
-5.50.3.67 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'
-
-5.50.3.68 Element/structure loads, VLD1 variants
-................................................
-
- * 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]'
-
- * 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]'
-
- * 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]'
-
- * 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]'
-
- * 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]'
-
- * uint64x2_t vld1q_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * int64x2_t vld1q_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
-5.50.3.69 Element/structure stores, VST1 variants
-.................................................
-
- * 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_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_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_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]'
-
-5.50.3.70 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]'
-
- * 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]'
-
- * 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]'
-
-5.50.3.71 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_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]'
-
-5.50.3.72 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]'
-
- * 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]'
-
- * 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]'
-
-5.50.3.73 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_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]'
-
-5.50.3.74 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]'
-
- * 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]'
-
- * 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]'
-
-5.50.3.75 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_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]'
-
-5.50.3.76 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)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * int64x1_t vand_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * 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'
-
-5.50.3.77 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)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * int64x1_t vorr_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * 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'
-
-5.50.3.78 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)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * int64x1_t veor_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * 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'
-
-5.50.3.79 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)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * int64x1_t vbic_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * 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'
-
-5.50.3.80 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)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * int64x1_t vorn_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * 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'
-
-5.50.3.81 Reinterpret casts
-...........................
-
- * poly8x8_t vreinterpret_p8_u32 (uint32x2_t)
-
- * poly8x8_t vreinterpret_p8_u16 (uint16x4_t)
-
- * poly8x8_t vreinterpret_p8_u8 (uint8x8_t)
-
- * poly8x8_t vreinterpret_p8_s32 (int32x2_t)
-
- * poly8x8_t vreinterpret_p8_s16 (int16x4_t)
-
- * poly8x8_t vreinterpret_p8_s8 (int8x8_t)
-
- * poly8x8_t vreinterpret_p8_u64 (uint64x1_t)
-
- * poly8x8_t vreinterpret_p8_s64 (int64x1_t)
-
- * poly8x8_t vreinterpret_p8_f32 (float32x2_t)
-
- * poly8x8_t vreinterpret_p8_p16 (poly16x4_t)
-
- * poly8x16_t vreinterpretq_p8_u32 (uint32x4_t)
-
- * poly8x16_t vreinterpretq_p8_u16 (uint16x8_t)
-
- * poly8x16_t vreinterpretq_p8_u8 (uint8x16_t)
-
- * poly8x16_t vreinterpretq_p8_s32 (int32x4_t)
-
- * poly8x16_t vreinterpretq_p8_s16 (int16x8_t)
-
- * poly8x16_t vreinterpretq_p8_s8 (int8x16_t)
-
- * poly8x16_t vreinterpretq_p8_u64 (uint64x2_t)
-
- * poly8x16_t vreinterpretq_p8_s64 (int64x2_t)
-
- * poly8x16_t vreinterpretq_p8_f32 (float32x4_t)
-
- * poly8x16_t vreinterpretq_p8_p16 (poly16x8_t)
-
- * poly16x4_t vreinterpret_p16_u32 (uint32x2_t)
-
- * poly16x4_t vreinterpret_p16_u16 (uint16x4_t)
-
- * poly16x4_t vreinterpret_p16_u8 (uint8x8_t)
-
- * poly16x4_t vreinterpret_p16_s32 (int32x2_t)
-
- * poly16x4_t vreinterpret_p16_s16 (int16x4_t)
-
- * poly16x4_t vreinterpret_p16_s8 (int8x8_t)
-
- * poly16x4_t vreinterpret_p16_u64 (uint64x1_t)
-
- * poly16x4_t vreinterpret_p16_s64 (int64x1_t)
-
- * poly16x4_t vreinterpret_p16_f32 (float32x2_t)
-
- * poly16x4_t vreinterpret_p16_p8 (poly8x8_t)
-
- * poly16x8_t vreinterpretq_p16_u32 (uint32x4_t)
-
- * poly16x8_t vreinterpretq_p16_u16 (uint16x8_t)
-
- * poly16x8_t vreinterpretq_p16_u8 (uint8x16_t)
-
- * poly16x8_t vreinterpretq_p16_s32 (int32x4_t)
-
- * poly16x8_t vreinterpretq_p16_s16 (int16x8_t)
-
- * poly16x8_t vreinterpretq_p16_s8 (int8x16_t)
-
- * poly16x8_t vreinterpretq_p16_u64 (uint64x2_t)
-
- * poly16x8_t vreinterpretq_p16_s64 (int64x2_t)
-
- * poly16x8_t vreinterpretq_p16_f32 (float32x4_t)
-
- * poly16x8_t vreinterpretq_p16_p8 (poly8x16_t)
-
- * float32x2_t vreinterpret_f32_u32 (uint32x2_t)
-
- * float32x2_t vreinterpret_f32_u16 (uint16x4_t)
-
- * float32x2_t vreinterpret_f32_u8 (uint8x8_t)
-
- * float32x2_t vreinterpret_f32_s32 (int32x2_t)
-
- * float32x2_t vreinterpret_f32_s16 (int16x4_t)
-
- * float32x2_t vreinterpret_f32_s8 (int8x8_t)
-
- * float32x2_t vreinterpret_f32_u64 (uint64x1_t)
-
- * float32x2_t vreinterpret_f32_s64 (int64x1_t)
-
- * float32x2_t vreinterpret_f32_p16 (poly16x4_t)
-
- * float32x2_t vreinterpret_f32_p8 (poly8x8_t)
-
- * float32x4_t vreinterpretq_f32_u32 (uint32x4_t)
-
- * float32x4_t vreinterpretq_f32_u16 (uint16x8_t)
-
- * float32x4_t vreinterpretq_f32_u8 (uint8x16_t)
-
- * float32x4_t vreinterpretq_f32_s32 (int32x4_t)
-
- * float32x4_t vreinterpretq_f32_s16 (int16x8_t)
-
- * float32x4_t vreinterpretq_f32_s8 (int8x16_t)
-
- * float32x4_t vreinterpretq_f32_u64 (uint64x2_t)
-
- * float32x4_t vreinterpretq_f32_s64 (int64x2_t)
-
- * float32x4_t vreinterpretq_f32_p16 (poly16x8_t)
-
- * float32x4_t vreinterpretq_f32_p8 (poly8x16_t)
-
- * int64x1_t vreinterpret_s64_u32 (uint32x2_t)
-
- * int64x1_t vreinterpret_s64_u16 (uint16x4_t)
-
- * int64x1_t vreinterpret_s64_u8 (uint8x8_t)
-
- * int64x1_t vreinterpret_s64_s32 (int32x2_t)
-
- * int64x1_t vreinterpret_s64_s16 (int16x4_t)
-
- * int64x1_t vreinterpret_s64_s8 (int8x8_t)
-
- * int64x1_t vreinterpret_s64_u64 (uint64x1_t)
-
- * int64x1_t vreinterpret_s64_f32 (float32x2_t)
-
- * int64x1_t vreinterpret_s64_p16 (poly16x4_t)
-
- * int64x1_t vreinterpret_s64_p8 (poly8x8_t)
-
- * int64x2_t vreinterpretq_s64_u32 (uint32x4_t)
-
- * int64x2_t vreinterpretq_s64_u16 (uint16x8_t)
-
- * int64x2_t vreinterpretq_s64_u8 (uint8x16_t)
-
- * int64x2_t vreinterpretq_s64_s32 (int32x4_t)
-
- * int64x2_t vreinterpretq_s64_s16 (int16x8_t)
-
- * int64x2_t vreinterpretq_s64_s8 (int8x16_t)
-
- * int64x2_t vreinterpretq_s64_u64 (uint64x2_t)
-
- * int64x2_t vreinterpretq_s64_f32 (float32x4_t)
-
- * int64x2_t vreinterpretq_s64_p16 (poly16x8_t)
-
- * int64x2_t vreinterpretq_s64_p8 (poly8x16_t)
-
- * uint64x1_t vreinterpret_u64_u32 (uint32x2_t)
-
- * uint64x1_t vreinterpret_u64_u16 (uint16x4_t)
-
- * uint64x1_t vreinterpret_u64_u8 (uint8x8_t)
-
- * uint64x1_t vreinterpret_u64_s32 (int32x2_t)
-
- * uint64x1_t vreinterpret_u64_s16 (int16x4_t)
-
- * uint64x1_t vreinterpret_u64_s8 (int8x8_t)
-
- * uint64x1_t vreinterpret_u64_s64 (int64x1_t)
-
- * uint64x1_t vreinterpret_u64_f32 (float32x2_t)
-
- * uint64x1_t vreinterpret_u64_p16 (poly16x4_t)
-
- * uint64x1_t vreinterpret_u64_p8 (poly8x8_t)
-
- * uint64x2_t vreinterpretq_u64_u32 (uint32x4_t)
-
- * uint64x2_t vreinterpretq_u64_u16 (uint16x8_t)
-
- * uint64x2_t vreinterpretq_u64_u8 (uint8x16_t)
-
- * uint64x2_t vreinterpretq_u64_s32 (int32x4_t)
-
- * uint64x2_t vreinterpretq_u64_s16 (int16x8_t)
-
- * uint64x2_t vreinterpretq_u64_s8 (int8x16_t)
-
- * uint64x2_t vreinterpretq_u64_s64 (int64x2_t)
-
- * uint64x2_t vreinterpretq_u64_f32 (float32x4_t)
-
- * uint64x2_t vreinterpretq_u64_p16 (poly16x8_t)
-
- * uint64x2_t vreinterpretq_u64_p8 (poly8x16_t)
-
- * int8x8_t vreinterpret_s8_u32 (uint32x2_t)
-
- * int8x8_t vreinterpret_s8_u16 (uint16x4_t)
-
- * int8x8_t vreinterpret_s8_u8 (uint8x8_t)
-
- * int8x8_t vreinterpret_s8_s32 (int32x2_t)
-
- * int8x8_t vreinterpret_s8_s16 (int16x4_t)
-
- * int8x8_t vreinterpret_s8_u64 (uint64x1_t)
-
- * int8x8_t vreinterpret_s8_s64 (int64x1_t)
-
- * int8x8_t vreinterpret_s8_f32 (float32x2_t)
-
- * int8x8_t vreinterpret_s8_p16 (poly16x4_t)
-
- * int8x8_t vreinterpret_s8_p8 (poly8x8_t)
-
- * int8x16_t vreinterpretq_s8_u32 (uint32x4_t)
-
- * int8x16_t vreinterpretq_s8_u16 (uint16x8_t)
-
- * int8x16_t vreinterpretq_s8_u8 (uint8x16_t)
-
- * int8x16_t vreinterpretq_s8_s32 (int32x4_t)
-
- * int8x16_t vreinterpretq_s8_s16 (int16x8_t)
-
- * int8x16_t vreinterpretq_s8_u64 (uint64x2_t)
-
- * int8x16_t vreinterpretq_s8_s64 (int64x2_t)
-
- * int8x16_t vreinterpretq_s8_f32 (float32x4_t)
-
- * int8x16_t vreinterpretq_s8_p16 (poly16x8_t)
-
- * int8x16_t vreinterpretq_s8_p8 (poly8x16_t)
-
- * int16x4_t vreinterpret_s16_u32 (uint32x2_t)
-
- * int16x4_t vreinterpret_s16_u16 (uint16x4_t)
-
- * int16x4_t vreinterpret_s16_u8 (uint8x8_t)
-
- * int16x4_t vreinterpret_s16_s32 (int32x2_t)
-
- * int16x4_t vreinterpret_s16_s8 (int8x8_t)
-
- * int16x4_t vreinterpret_s16_u64 (uint64x1_t)
-
- * int16x4_t vreinterpret_s16_s64 (int64x1_t)
-
- * int16x4_t vreinterpret_s16_f32 (float32x2_t)
-
- * int16x4_t vreinterpret_s16_p16 (poly16x4_t)
-
- * int16x4_t vreinterpret_s16_p8 (poly8x8_t)
-
- * int16x8_t vreinterpretq_s16_u32 (uint32x4_t)
-
- * int16x8_t vreinterpretq_s16_u16 (uint16x8_t)
-
- * int16x8_t vreinterpretq_s16_u8 (uint8x16_t)
-
- * int16x8_t vreinterpretq_s16_s32 (int32x4_t)
-
- * int16x8_t vreinterpretq_s16_s8 (int8x16_t)
-
- * int16x8_t vreinterpretq_s16_u64 (uint64x2_t)
-
- * int16x8_t vreinterpretq_s16_s64 (int64x2_t)
-
- * int16x8_t vreinterpretq_s16_f32 (float32x4_t)
-
- * int16x8_t vreinterpretq_s16_p16 (poly16x8_t)
-
- * int16x8_t vreinterpretq_s16_p8 (poly8x16_t)
-
- * int32x2_t vreinterpret_s32_u32 (uint32x2_t)
-
- * int32x2_t vreinterpret_s32_u16 (uint16x4_t)
-
- * int32x2_t vreinterpret_s32_u8 (uint8x8_t)
-
- * int32x2_t vreinterpret_s32_s16 (int16x4_t)
-
- * int32x2_t vreinterpret_s32_s8 (int8x8_t)
-
- * int32x2_t vreinterpret_s32_u64 (uint64x1_t)
-
- * int32x2_t vreinterpret_s32_s64 (int64x1_t)
-
- * int32x2_t vreinterpret_s32_f32 (float32x2_t)
-
- * int32x2_t vreinterpret_s32_p16 (poly16x4_t)
-
- * int32x2_t vreinterpret_s32_p8 (poly8x8_t)
-
- * int32x4_t vreinterpretq_s32_u32 (uint32x4_t)
-
- * int32x4_t vreinterpretq_s32_u16 (uint16x8_t)
-
- * int32x4_t vreinterpretq_s32_u8 (uint8x16_t)
-
- * int32x4_t vreinterpretq_s32_s16 (int16x8_t)
-
- * int32x4_t vreinterpretq_s32_s8 (int8x16_t)
-
- * int32x4_t vreinterpretq_s32_u64 (uint64x2_t)
-
- * int32x4_t vreinterpretq_s32_s64 (int64x2_t)
-
- * int32x4_t vreinterpretq_s32_f32 (float32x4_t)
-
- * int32x4_t vreinterpretq_s32_p16 (poly16x8_t)
-
- * int32x4_t vreinterpretq_s32_p8 (poly8x16_t)
-
- * uint8x8_t vreinterpret_u8_u32 (uint32x2_t)
-
- * uint8x8_t vreinterpret_u8_u16 (uint16x4_t)
-
- * uint8x8_t vreinterpret_u8_s32 (int32x2_t)
-
- * uint8x8_t vreinterpret_u8_s16 (int16x4_t)
-
- * uint8x8_t vreinterpret_u8_s8 (int8x8_t)
-
- * uint8x8_t vreinterpret_u8_u64 (uint64x1_t)
-
- * uint8x8_t vreinterpret_u8_s64 (int64x1_t)
-
- * uint8x8_t vreinterpret_u8_f32 (float32x2_t)
-
- * uint8x8_t vreinterpret_u8_p16 (poly16x4_t)
-
- * uint8x8_t vreinterpret_u8_p8 (poly8x8_t)
-
- * uint8x16_t vreinterpretq_u8_u32 (uint32x4_t)
-
- * uint8x16_t vreinterpretq_u8_u16 (uint16x8_t)
-
- * uint8x16_t vreinterpretq_u8_s32 (int32x4_t)
-
- * uint8x16_t vreinterpretq_u8_s16 (int16x8_t)
-
- * uint8x16_t vreinterpretq_u8_s8 (int8x16_t)
-
- * uint8x16_t vreinterpretq_u8_u64 (uint64x2_t)
-
- * uint8x16_t vreinterpretq_u8_s64 (int64x2_t)
-
- * uint8x16_t vreinterpretq_u8_f32 (float32x4_t)
-
- * uint8x16_t vreinterpretq_u8_p16 (poly16x8_t)
-
- * uint8x16_t vreinterpretq_u8_p8 (poly8x16_t)
-
- * uint16x4_t vreinterpret_u16_u32 (uint32x2_t)
-
- * uint16x4_t vreinterpret_u16_u8 (uint8x8_t)
-
- * uint16x4_t vreinterpret_u16_s32 (int32x2_t)
-
- * uint16x4_t vreinterpret_u16_s16 (int16x4_t)
-
- * uint16x4_t vreinterpret_u16_s8 (int8x8_t)
-
- * uint16x4_t vreinterpret_u16_u64 (uint64x1_t)
-
- * uint16x4_t vreinterpret_u16_s64 (int64x1_t)
-
- * uint16x4_t vreinterpret_u16_f32 (float32x2_t)
-
- * uint16x4_t vreinterpret_u16_p16 (poly16x4_t)
-
- * uint16x4_t vreinterpret_u16_p8 (poly8x8_t)
-
- * uint16x8_t vreinterpretq_u16_u32 (uint32x4_t)
-
- * uint16x8_t vreinterpretq_u16_u8 (uint8x16_t)
-
- * uint16x8_t vreinterpretq_u16_s32 (int32x4_t)
-
- * uint16x8_t vreinterpretq_u16_s16 (int16x8_t)
-
- * uint16x8_t vreinterpretq_u16_s8 (int8x16_t)
-
- * uint16x8_t vreinterpretq_u16_u64 (uint64x2_t)
-
- * uint16x8_t vreinterpretq_u16_s64 (int64x2_t)
-
- * uint16x8_t vreinterpretq_u16_f32 (float32x4_t)
-
- * uint16x8_t vreinterpretq_u16_p16 (poly16x8_t)
-
- * uint16x8_t vreinterpretq_u16_p8 (poly8x16_t)
-
- * uint32x2_t vreinterpret_u32_u16 (uint16x4_t)
-
- * uint32x2_t vreinterpret_u32_u8 (uint8x8_t)
-
- * uint32x2_t vreinterpret_u32_s32 (int32x2_t)
-
- * uint32x2_t vreinterpret_u32_s16 (int16x4_t)
-
- * uint32x2_t vreinterpret_u32_s8 (int8x8_t)
-
- * uint32x2_t vreinterpret_u32_u64 (uint64x1_t)
-
- * uint32x2_t vreinterpret_u32_s64 (int64x1_t)
-
- * uint32x2_t vreinterpret_u32_f32 (float32x2_t)
-
- * uint32x2_t vreinterpret_u32_p16 (poly16x4_t)
-
- * uint32x2_t vreinterpret_u32_p8 (poly8x8_t)
-
- * uint32x4_t vreinterpretq_u32_u16 (uint16x8_t)
-
- * uint32x4_t vreinterpretq_u32_u8 (uint8x16_t)
-
- * uint32x4_t vreinterpretq_u32_s32 (int32x4_t)
-
- * uint32x4_t vreinterpretq_u32_s16 (int16x8_t)
-
- * uint32x4_t vreinterpretq_u32_s8 (int8x16_t)
-
- * uint32x4_t vreinterpretq_u32_u64 (uint64x2_t)
-
- * uint32x4_t vreinterpretq_u32_s64 (int64x2_t)
-
- * uint32x4_t vreinterpretq_u32_f32 (float32x4_t)
-
- * uint32x4_t vreinterpretq_u32_p16 (poly16x8_t)
-
- * uint32x4_t vreinterpretq_u32_p8 (poly8x16_t)
-
-\1f
-File: gcc.info, Node: Blackfin Built-in Functions, Next: FR-V Built-in Functions, Prev: ARM NEON Intrinsics, Up: Target Builtins
-
-5.50.4 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)
-
-\1f
-File: gcc.info, Node: FR-V Built-in Functions, Next: X86 Built-in Functions, Prev: Blackfin Built-in Functions, Up: Target Builtins
-
-5.50.5 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::
-
-\1f
-File: gcc.info, Node: Argument Types, Next: Directly-mapped Integer Functions, Up: FR-V Built-in Functions
-
-5.50.5.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 will
-select 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.
-
-\1f
-File: gcc.info, Node: Directly-mapped Integer Functions, Next: Directly-mapped Media Functions, Prev: Argument Types, Up: FR-V Built-in Functions
-
-5.50.5.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'
-
-\1f
-File: gcc.info, Node: Directly-mapped Media Functions, Next: Raw read/write Functions, Prev: Directly-mapped Integer Functions, Up: FR-V Built-in Functions
-
-5.50.5.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, B)' `MADDHSS A,B,C'
-`uw1 __MADDHUS (uw1, uw1)' `C = __MADDHUS (A, B)' `MADDHUS A,B,C'
-`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, sw1)' `__MCPXIS (C, A, B)' `MCPXIS A,B,C'
-`void __MCPXIU (acc, uw1, uw1)' `__MCPXIU (C, A, B)' `MCPXIU A,B,C'
-`void __MCPXRS (acc, sw1, sw1)' `__MCPXRS (C, A, B)' `MCPXRS A,B,C'
-`void __MCPXRU (acc, uw1, uw1)' `__MCPXRU (C, A, B)' `MCPXRU A,B,C'
-`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, B)' `MDCUTSSI A,#B,C'
-`uw2 __MDPACKH (uw2, uw2)' `C = __MDPACKH (A, B)' `MDPACKH A,B,C'
-`uw2 __MDROTLI (uw2, const)' `C = __MDROTLI (A, B)' `MDROTLI A,#B,C'
-`void __MDSUBACCS (acc, acc)' `__MDSUBACCS (B, A)' `MDSUBACCS A,B'
-`void __MDUNPACKH (uw1 *, uw2)' `__MDUNPACKH (&B, A)' `MDUNPACKH A,B'
-`uw2 __MEXPDHD (uw1, const)' `C = __MEXPDHD (A, B)' `MEXPDHD A,#B,C'
-`uw1 __MEXPDHW (uw1, const)' `C = __MEXPDHW (A, B)' `MEXPDHW A,#B,C'
-`uw1 __MHDSETH (uw1, const)' `C = __MHDSETH (A, B)' `MHDSETH A,#B,C'
-`sw1 __MHDSETS (const)' `B = __MHDSETS (A)' `MHDSETS #A,B'
-`uw1 __MHSETHIH (uw1, const)' `B = __MHSETHIH (B, A)' `MHSETHIH #A,B'
-`sw1 __MHSETHIS (sw1, const)' `B = __MHSETHIS (B, A)' `MHSETHIS #A,B'
-`uw1 __MHSETLOH (uw1, const)' `B = __MHSETLOH (B, A)' `MHSETLOH #A,B'
-`sw1 __MHSETLOS (sw1, const)' `B = __MHSETLOS (B, A)' `MHSETLOS #A,B'
-`uw1 __MHTOB (uw2)' `B = __MHTOB (A)' `MHTOB A,B'
-`void __MMACHS (acc, sw1, sw1)' `__MMACHS (C, A, B)' `MMACHS A,B,C'
-`void __MMACHU (acc, uw1, uw1)' `__MMACHU (C, A, B)' `MMACHU A,B,C'
-`void __MMRDHS (acc, sw1, sw1)' `__MMRDHS (C, A, B)' `MMRDHS A,B,C'
-`void __MMRDHU (acc, uw1, uw1)' `__MMRDHU (C, A, B)' `MMRDHU A,B,C'
-`void __MMULHS (acc, sw1, sw1)' `__MMULHS (C, A, B)' `MMULHS A,B,C'
-`void __MMULHU (acc, uw1, uw1)' `__MMULHU (C, A, B)' `MMULHU A,B,C'
-`void __MMULXHS (acc, sw1, sw1)' `__MMULXHS (C, A, B)' `MMULXHS A,B,C'
-`void __MMULXHU (acc, uw1, uw1)' `__MMULXHU (C, A, B)' `MMULXHU A,B,C'
-`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, B)' `MQADDHSS A,B,C'
-`uw2 __MQADDHUS (uw2, uw2)' `C = __MQADDHUS (A, B)' `MQADDHUS A,B,C'
-`void __MQCPXIS (acc, sw2, sw2)' `__MQCPXIS (C, A, B)' `MQCPXIS A,B,C'
-`void __MQCPXIU (acc, uw2, uw2)' `__MQCPXIU (C, A, B)' `MQCPXIU A,B,C'
-`void __MQCPXRS (acc, sw2, sw2)' `__MQCPXRS (C, A, B)' `MQCPXRS A,B,C'
-`void __MQCPXRU (acc, uw2, uw2)' `__MQCPXRU (C, A, B)' `MQCPXRU A,B,C'
-`sw2 __MQLCLRHS (sw2, sw2)' `C = __MQLCLRHS (A, B)' `MQLCLRHS A,B,C'
-`sw2 __MQLMTHS (sw2, sw2)' `C = __MQLMTHS (A, B)' `MQLMTHS A,B,C'
-`void __MQMACHS (acc, sw2, sw2)' `__MQMACHS (C, A, B)' `MQMACHS A,B,C'
-`void __MQMACHU (acc, uw2, uw2)' `__MQMACHU (C, A, B)' `MQMACHU A,B,C'
-`void __MQMACXHS (acc, sw2, `__MQMACXHS (C, A, B)' `MQMACXHS A,B,C'
-sw2)'
-`void __MQMULHS (acc, sw2, sw2)' `__MQMULHS (C, A, B)' `MQMULHS A,B,C'
-`void __MQMULHU (acc, uw2, uw2)' `__MQMULHU (C, A, B)' `MQMULHU A,B,C'
-`void __MQMULXHS (acc, sw2, `__MQMULXHS (C, A, B)' `MQMULXHS A,B,C'
-sw2)'
-`void __MQMULXHU (acc, uw2, `__MQMULXHU (C, A, B)' `MQMULXHU A,B,C'
-uw2)'
-`sw2 __MQSATHS (sw2, sw2)' `C = __MQSATHS (A, B)' `MQSATHS A,B,C'
-`uw2 __MQSLLHI (uw2, int)' `C = __MQSLLHI (A, B)' `MQSLLHI A,B,C'
-`sw2 __MQSRAHI (sw2, int)' `C = __MQSRAHI (A, B)' `MQSRAHI A,B,C'
-`sw2 __MQSUBHSS (sw2, sw2)' `C = __MQSUBHSS (A, B)' `MQSUBHSS A,B,C'
-`uw2 __MQSUBHUS (uw2, uw2)' `C = __MQSUBHUS (A, B)' `MQSUBHUS A,B,C'
-`void __MQXMACHS (acc, sw2, `__MQXMACHS (C, A, B)' `MQXMACHS A,B,C'
-sw2)'
-`void __MQXMACXHS (acc, sw2, `__MQXMACXHS (C, A, B)' `MQXMACXHS A,B,C'
-sw2)'
-`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, B)' `MSUBHSS A,B,C'
-`uw1 __MSUBHUS (uw1, uw1)' `C = __MSUBHUS (A, B)' `MSUBHUS A,B,C'
-`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'
-
-\1f
-File: gcc.info, Node: Raw read/write Functions, Next: Other Built-in Functions, Prev: Directly-mapped Media Functions, Up: FR-V Built-in Functions
-
-5.50.5.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)'
-
-\1f
-File: gcc.info, Node: Other Built-in Functions, Prev: Raw read/write Functions, Up: FR-V Built-in Functions
-
-5.50.5.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 will be issued in slot I1.
-
-\1f
-File: gcc.info, Node: X86 Built-in Functions, Next: MIPS DSP Built-in Functions, Prev: FR-V Built-in Functions, Up: Target Builtins
-
-5.50.6 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.
-
- Note that, 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
-which perform runtime 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 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'.
-
- 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_pextrw (v4hi, int)
- v4hi __builtin_ia32_pinsrw (v4hi, int, int)
- 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)
- v4si __builtin_ia32_cmpeqps (v4sf, v4sf)
- v4si __builtin_ia32_cmpltps (v4sf, v4sf)
- v4si __builtin_ia32_cmpleps (v4sf, v4sf)
- v4si __builtin_ia32_cmpgtps (v4sf, v4sf)
- v4si __builtin_ia32_cmpgeps (v4sf, v4sf)
- v4si __builtin_ia32_cmpunordps (v4sf, v4sf)
- v4si __builtin_ia32_cmpneqps (v4sf, v4sf)
- v4si __builtin_ia32_cmpnltps (v4sf, v4sf)
- v4si __builtin_ia32_cmpnleps (v4sf, v4sf)
- v4si __builtin_ia32_cmpngtps (v4sf, v4sf)
- v4si __builtin_ia32_cmpngeps (v4sf, v4sf)
- v4si __builtin_ia32_cmpordps (v4sf, v4sf)
- v4si __builtin_ia32_cmpeqss (v4sf, v4sf)
- v4si __builtin_ia32_cmpltss (v4sf, v4sf)
- v4si __builtin_ia32_cmpless (v4sf, v4sf)
- v4si __builtin_ia32_cmpunordss (v4sf, v4sf)
- v4si __builtin_ia32_cmpneqss (v4sf, v4sf)
- v4si __builtin_ia32_cmpnlts (v4sf, v4sf)
- v4si __builtin_ia32_cmpnless (v4sf, v4sf)
- v4si __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_loadaps (float *)'
- Generates the `movaps' machine instruction as a load from memory.
-
-`void __builtin_ia32_storeaps (float *, v4sf)'
- Generates the `movaps' machine instruction as a store to memory.
-
-`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_loadsss (float *)'
- Generates the `movss' machine instruction as a load from memory.
-
-`void __builtin_ia32_storess (float *, v4sf)'
- Generates the `movss' machine instruction as a store to 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_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)
- v2df __builtin_ia32_movddup (v2df)
- 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 `-msse3' is used.
-
-`v2df __builtin_ia32_loadddup (double const *)'
- Generates the `movddup' machine instruction as a load from memory.
-
- The following built-in functions are available when `-mssse3' is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
-
- 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
-with SSE registers.
-
- 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 `-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 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 `-msse5' is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
-
- v2df __builtin_ia32_comeqpd (v2df, v2df)
- v2df __builtin_ia32_comeqps (v2df, v2df)
- v4sf __builtin_ia32_comeqsd (v4sf, v4sf)
- v4sf __builtin_ia32_comeqss (v4sf, v4sf)
- v2df __builtin_ia32_comfalsepd (v2df, v2df)
- v2df __builtin_ia32_comfalseps (v2df, v2df)
- v4sf __builtin_ia32_comfalsesd (v4sf, v4sf)
- v4sf __builtin_ia32_comfalsess (v4sf, v4sf)
- v2df __builtin_ia32_comgepd (v2df, v2df)
- v2df __builtin_ia32_comgeps (v2df, v2df)
- v4sf __builtin_ia32_comgesd (v4sf, v4sf)
- v4sf __builtin_ia32_comgess (v4sf, v4sf)
- v2df __builtin_ia32_comgtpd (v2df, v2df)
- v2df __builtin_ia32_comgtps (v2df, v2df)
- v4sf __builtin_ia32_comgtsd (v4sf, v4sf)
- v4sf __builtin_ia32_comgtss (v4sf, v4sf)
- v2df __builtin_ia32_comlepd (v2df, v2df)
- v2df __builtin_ia32_comleps (v2df, v2df)
- v4sf __builtin_ia32_comlesd (v4sf, v4sf)
- v4sf __builtin_ia32_comless (v4sf, v4sf)
- v2df __builtin_ia32_comltpd (v2df, v2df)
- v2df __builtin_ia32_comltps (v2df, v2df)
- v4sf __builtin_ia32_comltsd (v4sf, v4sf)
- v4sf __builtin_ia32_comltss (v4sf, v4sf)
- v2df __builtin_ia32_comnepd (v2df, v2df)
- v2df __builtin_ia32_comneps (v2df, v2df)
- v4sf __builtin_ia32_comnesd (v4sf, v4sf)
- v4sf __builtin_ia32_comness (v4sf, v4sf)
- v2df __builtin_ia32_comordpd (v2df, v2df)
- v2df __builtin_ia32_comordps (v2df, v2df)
- v4sf __builtin_ia32_comordsd (v4sf, v4sf)
- v4sf __builtin_ia32_comordss (v4sf, v4sf)
- v2df __builtin_ia32_comtruepd (v2df, v2df)
- v2df __builtin_ia32_comtrueps (v2df, v2df)
- v4sf __builtin_ia32_comtruesd (v4sf, v4sf)
- v4sf __builtin_ia32_comtruess (v4sf, v4sf)
- v2df __builtin_ia32_comueqpd (v2df, v2df)
- v2df __builtin_ia32_comueqps (v2df, v2df)
- v4sf __builtin_ia32_comueqsd (v4sf, v4sf)
- v4sf __builtin_ia32_comueqss (v4sf, v4sf)
- v2df __builtin_ia32_comugepd (v2df, v2df)
- v2df __builtin_ia32_comugeps (v2df, v2df)
- v4sf __builtin_ia32_comugesd (v4sf, v4sf)
- v4sf __builtin_ia32_comugess (v4sf, v4sf)
- v2df __builtin_ia32_comugtpd (v2df, v2df)
- v2df __builtin_ia32_comugtps (v2df, v2df)
- v4sf __builtin_ia32_comugtsd (v4sf, v4sf)
- v4sf __builtin_ia32_comugtss (v4sf, v4sf)
- v2df __builtin_ia32_comulepd (v2df, v2df)
- v2df __builtin_ia32_comuleps (v2df, v2df)
- v4sf __builtin_ia32_comulesd (v4sf, v4sf)
- v4sf __builtin_ia32_comuless (v4sf, v4sf)
- v2df __builtin_ia32_comultpd (v2df, v2df)
- v2df __builtin_ia32_comultps (v2df, v2df)
- v4sf __builtin_ia32_comultsd (v4sf, v4sf)
- v4sf __builtin_ia32_comultss (v4sf, v4sf)
- v2df __builtin_ia32_comunepd (v2df, v2df)
- v2df __builtin_ia32_comuneps (v2df, v2df)
- v4sf __builtin_ia32_comunesd (v4sf, v4sf)
- v4sf __builtin_ia32_comuness (v4sf, v4sf)
- v2df __builtin_ia32_comunordpd (v2df, v2df)
- v2df __builtin_ia32_comunordps (v2df, v2df)
- v4sf __builtin_ia32_comunordsd (v4sf, v4sf)
- v4sf __builtin_ia32_comunordss (v4sf, v4sf)
- v2df __builtin_ia32_fmaddpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmaddps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmaddsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmaddss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmsubpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmsubps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmsubsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmsubss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmaddpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmaddps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmaddsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmaddss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmsubpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmsubps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmsubsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmsubss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_frczpd (v2df)
- v4sf __builtin_ia32_frczps (v4sf)
- v2df __builtin_ia32_frczsd (v2df, v2df)
- v4sf __builtin_ia32_frczss (v4sf, v4sf)
- v2di __builtin_ia32_pcmov (v2di, v2di, v2di)
- v2di __builtin_ia32_pcmov_v2di (v2di, v2di, v2di)
- v4si __builtin_ia32_pcmov_v4si (v4si, v4si, v4si)
- v8hi __builtin_ia32_pcmov_v8hi (v8hi, v8hi, v8hi)
- v16qi __builtin_ia32_pcmov_v16qi (v16qi, v16qi, v16qi)
- v2df __builtin_ia32_pcmov_v2df (v2df, v2df, v2df)
- v4sf __builtin_ia32_pcmov_v4sf (v4sf, v4sf, v4sf)
- v16qi __builtin_ia32_pcomeqb (v16qi, v16qi)
- v8hi __builtin_ia32_pcomeqw (v8hi, v8hi)
- v4si __builtin_ia32_pcomeqd (v4si, v4si)
- v2di __builtin_ia32_pcomeqq (v2di, v2di)
- v16qi __builtin_ia32_pcomequb (v16qi, v16qi)
- v4si __builtin_ia32_pcomequd (v4si, v4si)
- v2di __builtin_ia32_pcomequq (v2di, v2di)
- v8hi __builtin_ia32_pcomequw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomeqw (v8hi, v8hi)
- v16qi __builtin_ia32_pcomfalseb (v16qi, v16qi)
- v4si __builtin_ia32_pcomfalsed (v4si, v4si)
- v2di __builtin_ia32_pcomfalseq (v2di, v2di)
- v16qi __builtin_ia32_pcomfalseub (v16qi, v16qi)
- v4si __builtin_ia32_pcomfalseud (v4si, v4si)
- v2di __builtin_ia32_pcomfalseuq (v2di, v2di)
- v8hi __builtin_ia32_pcomfalseuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomfalsew (v8hi, v8hi)
- v16qi __builtin_ia32_pcomgeb (v16qi, v16qi)
- v4si __builtin_ia32_pcomged (v4si, v4si)
- v2di __builtin_ia32_pcomgeq (v2di, v2di)
- v16qi __builtin_ia32_pcomgeub (v16qi, v16qi)
- v4si __builtin_ia32_pcomgeud (v4si, v4si)
- v2di __builtin_ia32_pcomgeuq (v2di, v2di)
- v8hi __builtin_ia32_pcomgeuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomgew (v8hi, v8hi)
- v16qi __builtin_ia32_pcomgtb (v16qi, v16qi)
- v4si __builtin_ia32_pcomgtd (v4si, v4si)
- v2di __builtin_ia32_pcomgtq (v2di, v2di)
- v16qi __builtin_ia32_pcomgtub (v16qi, v16qi)
- v4si __builtin_ia32_pcomgtud (v4si, v4si)
- v2di __builtin_ia32_pcomgtuq (v2di, v2di)
- v8hi __builtin_ia32_pcomgtuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomgtw (v8hi, v8hi)
- v16qi __builtin_ia32_pcomleb (v16qi, v16qi)
- v4si __builtin_ia32_pcomled (v4si, v4si)
- v2di __builtin_ia32_pcomleq (v2di, v2di)
- v16qi __builtin_ia32_pcomleub (v16qi, v16qi)
- v4si __builtin_ia32_pcomleud (v4si, v4si)
- v2di __builtin_ia32_pcomleuq (v2di, v2di)
- v8hi __builtin_ia32_pcomleuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomlew (v8hi, v8hi)
- v16qi __builtin_ia32_pcomltb (v16qi, v16qi)
- v4si __builtin_ia32_pcomltd (v4si, v4si)
- v2di __builtin_ia32_pcomltq (v2di, v2di)
- v16qi __builtin_ia32_pcomltub (v16qi, v16qi)
- v4si __builtin_ia32_pcomltud (v4si, v4si)
- v2di __builtin_ia32_pcomltuq (v2di, v2di)
- v8hi __builtin_ia32_pcomltuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomltw (v8hi, v8hi)
- v16qi __builtin_ia32_pcomneb (v16qi, v16qi)
- v4si __builtin_ia32_pcomned (v4si, v4si)
- v2di __builtin_ia32_pcomneq (v2di, v2di)
- v16qi __builtin_ia32_pcomneub (v16qi, v16qi)
- v4si __builtin_ia32_pcomneud (v4si, v4si)
- v2di __builtin_ia32_pcomneuq (v2di, v2di)
- v8hi __builtin_ia32_pcomneuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomnew (v8hi, v8hi)
- v16qi __builtin_ia32_pcomtrueb (v16qi, v16qi)
- v4si __builtin_ia32_pcomtrued (v4si, v4si)
- v2di __builtin_ia32_pcomtrueq (v2di, v2di)
- v16qi __builtin_ia32_pcomtrueub (v16qi, v16qi)
- v4si __builtin_ia32_pcomtrueud (v4si, v4si)
- v2di __builtin_ia32_pcomtrueuq (v2di, v2di)
- v8hi __builtin_ia32_pcomtrueuw (v8hi, v8hi)
- v8hi __builtin_ia32_pcomtruew (v8hi, v8hi)
- v4df __builtin_ia32_permpd (v2df, v2df, v16qi)
- v4sf __builtin_ia32_permps (v4sf, v4sf, v16qi)
- v4si __builtin_ia32_phaddbd (v16qi)
- v2di __builtin_ia32_phaddbq (v16qi)
- v8hi __builtin_ia32_phaddbw (v16qi)
- v2di __builtin_ia32_phadddq (v4si)
- v4si __builtin_ia32_phaddubd (v16qi)
- v2di __builtin_ia32_phaddubq (v16qi)
- v8hi __builtin_ia32_phaddubw (v16qi)
- v2di __builtin_ia32_phaddudq (v4si)
- v4si __builtin_ia32_phadduwd (v8hi)
- v2di __builtin_ia32_phadduwq (v8hi)
- v4si __builtin_ia32_phaddwd (v8hi)
- v2di __builtin_ia32_phaddwq (v8hi)
- v8hi __builtin_ia32_phsubbw (v16qi)
- v2di __builtin_ia32_phsubdq (v4si)
- v4si __builtin_ia32_phsubwd (v8hi)
- v4si __builtin_ia32_pmacsdd (v4si, v4si, v4si)
- v2di __builtin_ia32_pmacsdqh (v4si, v4si, v2di)
- v2di __builtin_ia32_pmacsdql (v4si, v4si, v2di)
- v4si __builtin_ia32_pmacssdd (v4si, v4si, v4si)
- v2di __builtin_ia32_pmacssdqh (v4si, v4si, v2di)
- v2di __builtin_ia32_pmacssdql (v4si, v4si, v2di)
- v4si __builtin_ia32_pmacsswd (v8hi, v8hi, v4si)
- v8hi __builtin_ia32_pmacssww (v8hi, v8hi, v8hi)
- v4si __builtin_ia32_pmacswd (v8hi, v8hi, v4si)
- v8hi __builtin_ia32_pmacsww (v8hi, v8hi, v8hi)
- v4si __builtin_ia32_pmadcsswd (v8hi, v8hi, v4si)
- v4si __builtin_ia32_pmadcswd (v8hi, v8hi, v4si)
- v16qi __builtin_ia32_pperm (v16qi, v16qi, v16qi)
- v16qi __builtin_ia32_protb (v16qi, v16qi)
- v4si __builtin_ia32_protd (v4si, v4si)
- v2di __builtin_ia32_protq (v2di, v2di)
- v8hi __builtin_ia32_protw (v8hi, v8hi)
- v16qi __builtin_ia32_pshab (v16qi, v16qi)
- v4si __builtin_ia32_pshad (v4si, v4si)
- v2di __builtin_ia32_pshaq (v2di, v2di)
- v8hi __builtin_ia32_pshaw (v8hi, v8hi)
- v16qi __builtin_ia32_pshlb (v16qi, v16qi)
- v4si __builtin_ia32_pshld (v4si, v4si)
- v2di __builtin_ia32_pshlq (v2di, v2di)
- v8hi __builtin_ia32_pshlw (v8hi, v8hi)
-
- The following builtin-in functions are available when `-msse5' is
-used. The second argument must be an integer constant and generate the
-machine instruction that is part of the name with the `_imm' suffix
-removed.
-
- v16qi __builtin_ia32_protb_imm (v16qi, int)
- v4si __builtin_ia32_protd_imm (v4si, int)
- v2di __builtin_ia32_protq_imm (v2di, int)
- v8hi __builtin_ia32_protw_imm (v8hi, int)
-
- 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_pfrsqrtit1 (v2sf, 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)
-
-\1f
-File: gcc.info, Node: MIPS DSP Built-in Functions, Next: MIPS Paired-Single Support, Prev: X86 Built-in Functions, Up: Target Builtins
-
-5.50.7 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 will not delete these
-instructions and it will 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 will
-set 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 will be 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)
- i32 __builtin_mips_bposge32 (void)
-
- 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);
- 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);
- 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);
- a64 __builtin_mips_mult (i32, i32);
- a64 __builtin_mips_multu (ui32, ui32);
- 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);
-
-\1f
-File: gcc.info, Node: MIPS Paired-Single Support, Next: MIPS Loongson Built-in Functions, Prev: MIPS DSP Built-in Functions, Up: Target Builtins
-
-5.50.8 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 will set the lower
-half of `a' to `1.5' on little-endian targets and `9.1' on big-endian
-targets.
-
-\1f
-File: gcc.info, Node: MIPS Loongson Built-in Functions, Next: Other MIPS Built-in Functions, Prev: MIPS Paired-Single Support, Up: Target Builtins
-
-5.50.9 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::
-
-\1f
-File: gcc.info, Node: Paired-Single Arithmetic, Next: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions
-
-5.50.9.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'.
-
-\1f
-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
-
-5.50.9.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 will be 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 ();
-
-\1f
-File: gcc.info, Node: MIPS-3D Built-in Functions, Prev: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions
-
-5.50.9.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 ();
-
-\1f
-File: gcc.info, Node: picoChip Built-in Functions, Next: PowerPC AltiVec Built-in Functions, Prev: Other MIPS Built-in Functions, Up: Target Builtins
-
-5.50.10 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
- which 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 will stop execution. This built-in is useful
- for implementing assertions.
-
-
-\1f
-File: gcc.info, Node: Other MIPS Built-in Functions, Next: picoChip Built-in Functions, Prev: MIPS Loongson Built-in Functions, Up: Target Builtins
-
-5.50.11 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.
-
-\1f
-File: gcc.info, Node: PowerPC AltiVec Built-in Functions, Next: SPARC VIS Built-in Functions, Prev: picoChip Built-in Functions, Up: Target Builtins
-
-5.50.12 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
-
- 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_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_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);
-
-\1f
-File: gcc.info, Node: SPARC VIS Built-in Functions, Next: SPU Built-in Functions, Prev: PowerPC AltiVec Built-in Functions, Up: Target Builtins
-
-5.50.13 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 v2si __attribute__ ((vector_size (8)));
- typedef short v4hi __attribute__ ((vector_size (8)));
- typedef short v2hi __attribute__ ((vector_size (4)));
- typedef char v8qi __attribute__ ((vector_size (8)));
- typedef char v4qi __attribute__ ((vector_size (4)));
-
- void * __builtin_vis_alignaddr (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, v4hi);
- v4hi __builtin_vis_fmul8x16al (v4qi, v4hi);
- 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, v2si);
- v2hi __builtin_vis_fpackfix (v2si);
- v8qi __builtin_vis_fpmerge (v4qi, v4qi);
-
- int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);
-
-\1f
-File: gcc.info, Node: SPU Built-in Functions, Prev: SPARC VIS Built-in Functions, Up: Target Builtins
-
-5.50.14 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.
-
-\1f
-File: gcc.info, Node: Target Format Checks, Next: Pragmas, Prev: Target Builtins, Up: C Extensions
-
-5.51 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::
-
-\1f
-File: gcc.info, Node: Solaris Format Checks, Up: Target Format Checks
-
-5.51.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.
-
-\1f
-File: gcc.info, Node: Pragmas, Next: Unnamed Fields, Prev: Target Format Checks, Up: C Extensions
-
-5.52 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::
-* 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::
-
-\1f
-File: gcc.info, Node: ARM Pragmas, Next: M32C Pragmas, Up: Pragmas
-
-5.52.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.
-
-\1f
-File: gcc.info, Node: M32C Pragmas, Next: RS/6000 and PowerPC Pragmas, Prev: ARM Pragmas, Up: Pragmas
-
-5.52.2 M32C Pragmas
--------------------
-
-`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.
-
-
-\1f
-File: gcc.info, Node: RS/6000 and PowerPC Pragmas, Next: Darwin Pragmas, Prev: M32C Pragmas, Up: Pragmas
-
-5.52.3 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.
-
-\1f
-File: gcc.info, Node: Darwin Pragmas, Next: Solaris Pragmas, Prev: RS/6000 and PowerPC Pragmas, Up: Pragmas
-
-5.52.4 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 will 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.
-
-\1f
-File: gcc.info, Node: Solaris Pragmas, Next: Symbol-Renaming Pragmas, Prev: Darwin Pragmas, Up: Pragmas
-
-5.52.5 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.
-
-
-\1f
-File: gcc.info, Node: Symbol-Renaming Pragmas, Next: Structure-Packing Pragmas, Prev: Solaris Pragmas, Up: Pragmas
-
-5.52.6 Symbol-Renaming Pragmas
-------------------------------
-
-For compatibility with the Solaris and Tru64 UNIX system headers, GCC
-supports two `#pragma' directives which change the name used in
-assembly for a given declaration. These pragmas are only available on
-platforms whose system headers need them. 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' will
- be defined if this pragma is available (currently only on Solaris).
-
-`extern_prefix STRING'
- This pragma causes all subsequent external function and variable
- declarations to have STRING prepended to their assembly symbols.
- This effect may be terminated with another `extern_prefix' pragma
- whose argument is an empty string. The preprocessor macro
- `__PRAGMA_EXTERN_PREFIX' will be defined if this pragma is
- available (currently only on Tru64 UNIX).
-
- These pragmas 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.
-
- 5. If `#pragma extern_prefix' is in effect, and a declaration occurs
- with an asm label attached, the prefix is silently ignored for
- that declaration.
-
- 6. If `#pragma extern_prefix' and `#pragma redefine_extname' apply to
- the same declaration, whichever triggered first wins, and a
- warning issues if they contradict each other. (We would like to
- have `#pragma redefine_extname' always win, for consistency with
- asm labels, but if `#pragma extern_prefix' triggers first we have
- no way of knowing that that happened.)
-
-\1f
-File: gcc.info, Node: Structure-Packing Pragmas, Next: Weak Pragmas, Prev: Symbol-Renaming Pragmas, Up: Pragmas
-
-5.52.7 Structure-Packing Pragmas
---------------------------------
-
-For compatibility with Microsoft Windows compilers, GCC supports a set
-of `#pragma' directives which change the maximum alignment of members
-of structures (other than zero-width bitfields), 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.
-
-\1f
-File: gcc.info, Node: Weak Pragmas, Next: Diagnostic Pragmas, Prev: Structure-Packing Pragmas, Up: Pragmas
-
-5.52.8 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, but must appear before either its
- first use or its definition. 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.
-
-\1f
-File: gcc.info, Node: Diagnostic Pragmas, Next: Visibility Pragmas, Prev: Weak Pragmas, Up: Pragmas
-
-5.52.9 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 which 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. Also,
- while it is syntactically valid to put these pragmas anywhere in
- your sources, the only supported location for them is before any
- data or functions are defined. Doing otherwise may result in
- unpredictable results depending on how the optimizer manages your
- sources. If the same option is listed multiple times, the last
- one specified is the one that is in effect. This pragma is not
- intended to be a general purpose replacement for command line
- options, but for implementing strict control over project policies.
-
-
- 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'.
-
-
-\1f
-File: gcc.info, Node: Visibility Pragmas, Next: Push/Pop Macro Pragmas, Prev: Diagnostic Pragmas, Up: Pragmas
-
-5.52.10 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.
-
-
-\1f
-File: gcc.info, Node: Push/Pop Macro Pragmas, Next: Function Specific Option Pragmas, Prev: Visibility Pragmas, Up: Pragmas
-
-5.52.11 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'.
-
-\1f
-File: gcc.info, Node: Function Specific Option Pragmas, Prev: Push/Pop Macro Pragmas, Up: Pragmas
-
-5.52.12 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 will be
- 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 not implemented in GCC versions
- earlier than 4.4, and is currently only implemented for the 386
- and x86_64 backends.
-
-`#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
- will be 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.
-
-\1f
-File: gcc.info, Node: Unnamed Fields, Next: Thread-Local, Prev: Pragmas, Up: C Extensions
-
-5.53 Unnamed struct/union fields within structs/unions
-======================================================
-
-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, the user would be 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, this structure:
-
- struct {
- int a;
- struct {
- int a;
- };
- } foo;
-
- It is ambiguous which `a' is being referred to with `foo.a'. Such
-constructs are not supported and must be avoided. In the future, such
-constructs may be detected and treated as compilation errors.
-
- 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.
-
-\1f
-File: gcc.info, Node: Thread-Local, Next: Binary constants, Prev: Unnamed Fields, Up: C Extensions
-
-5.54 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 run-time 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://people.redhat.com/drepper/tls.pdf) for a detailed explanation of
-the four thread-local storage addressing models, and how the run-time
-is expected to function.
-
-* Menu:
-
-* C99 Thread-Local Edits::
-* C++98 Thread-Local Edits::
-
-\1f
-File: gcc.info, Node: C99 Thread-Local Edits, Next: C++98 Thread-Local Edits, Up: Thread-Local
-
-5.54.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.
-
-\1f
-File: gcc.info, Node: C++98 Thread-Local Edits, Prev: C99 Thread-Local Edits, Up: Thread-Local
-
-5.54.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 which 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'.
-
-\1f
-File: gcc.info, Node: Binary constants, Prev: Thread-Local, Up: C Extensions
-
-5.55 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.
-
-\1f
-File: gcc.info, Node: C++ Extensions, Next: Objective-C, Prev: C Extensions, Up: Top
-
-6 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:
-
-* 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.
-* 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++.
-
-\1f
-File: gcc.info, Node: Volatiles, Next: Restricted Pointers, Up: C++ Extensions
-
-6.1 When is a Volatile Object Accessed?
-=======================================
-
-Both the C and C++ standard have the concept of volatile objects. These
-are normally accessed by pointers and used for accessing hardware. The
-standards encourage compilers to refrain from optimizations concerning
-accesses to volatile objects. The C standard leaves it implementation
-defined as to what constitutes a volatile access. The C++ standard
-omits to specify this, except to say that C++ should behave in a
-similar manner to C with respect to volatiles, where possible. The
-minimum either standard specifies 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 which occur between sequence points, but
-cannot do so for accesses across a sequence point. The use of
-volatiles does not allow you to violate the restriction on updating
-objects multiple times within a sequence point.
-
- *Note Volatile qualifier and the C compiler: Qualifiers implementation.
-
- The behavior differs slightly between C and C++ in the non-obvious
-cases:
-
- volatile int *src = SOMEVALUE;
- *src;
-
- With C, such expressions are rvalues, and GCC interprets this either
-as a read of the volatile object being pointed to or only as request to
-evaluate the side-effects. 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 this lvalue to rvalue conversion
-which may be responsible for causing an access. However, 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 when the value is unused 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.
-
-\1f
-File: gcc.info, Node: Restricted Pointers, Next: Vague Linkage, Prev: Volatiles, Up: C++ Extensions
-
-6.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 will have 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 which
-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.
-
-\1f
-File: gcc.info, Node: Vague Linkage, Next: C++ Interface, Prev: Restricted Pointers, Up: C++ Extensions
-
-6.3 Vague Linkage
-=================
-
-There are several constructs in C++ which 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 will always require 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 will still be emitted in every translation unit which
- 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 runtime. 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
-will use them. This way one copy will override all the others, but the
-unused copies will still take up space in the executable.
-
- For targets which do not support either COMDAT or weak symbols, most
-entities with vague linkage will be emitted as local symbols to avoid
-duplicate definition errors from the linker. This will not happen for
-local statics in inlines, however, as having multiple copies will
-almost certainly break things.
-
- *Note Declarations and Definitions in One Header: C++ Interface, for
-another way to control placement of these constructs.
-
-\1f
-File: gcc.info, Node: C++ Interface, Next: Template Instantiation, Prev: Vague Linkage, Up: C++ Extensions
-
-6.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 will not be generated (unless the main input source
- file itself uses `#pragma implementation'). Instead, the object
- files will 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 were
-not inlined, you will get linker errors.
-
- ---------- Footnotes ----------
-
- (1) A file's "basename" was the name stripped of all leading path
-information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
-
-\1f
-File: gcc.info, Node: Template Instantiation, Next: Bound member functions, Prev: C++ Interface, Up: C++ Extensions
-
-6.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.
-
- A future version of G++ will support a hybrid model whereby the
-compiler will emit any instantiations for which the template definition
-is included in the compile, and store template definitions and
-instantiation context information into the object file for the rest.
-The link wrapper will extract that information as necessary and invoke
-the compiler to produce the remaining instantiations. The linker will
-then combine duplicate instantiations.
-
- In the mean time, you have the following options for dealing with
-template instantiations:
-
- 1. Compile your template-using code with `-frepo'. The compiler will
- generate files with the extension `.rpo' listing all of the
- template instantiations used in the corresponding object files
- which could be instantiated there; the link wrapper, `collect2',
- will then update 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 will continue to place the instantiations in the same
- files.
-
- This is your best option for application code written for the
- Borland model, as it will just work. Code written for the Cfront
- model will need 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.
-
- G++ has extended the template instantiation syntax given in the ISO
- standard to allow forward declaration of explicit instantiations
- (with `extern'), 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 will work fine, but
- each translation unit will contain instances of each of the
- templates it uses. In a large program, this can lead to an
- unacceptable amount of code duplication.
-
-\1f
-File: gcc.info, Node: Bound member functions, Next: C++ Attributes, Prev: Template Instantiation, Up: C++ Extensions
-
-6.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 will still be paying 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.
-
-\1f
-File: gcc.info, Node: C++ Attributes, Next: Namespace Association, Prev: Bound member functions, Up: C++ Extensions
-
-6.7 C++-Specific Variable, Function, and Type Attributes
-========================================================
-
-Some attributes only make sense for C++ programs.
-
-`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 has reversed 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 will be dispatched using GCJ's interface table
- mechanism, instead of regular virtual table dispatch.
-
-
- See also *note Namespace Association::.
-
-\1f
-File: gcc.info, Node: Namespace Association, Next: Type Traits, Prev: C++ Attributes, Up: C++ Extensions
-
-6.8 Namespace Association
-=========================
-
-*Caution:* The semantics of this extension are not fully defined.
-Users should refrain from using this extension as its semantics may
-change subtly over time. It is possible that 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>());
- }
-
-\1f
-File: gcc.info, Node: Type Traits, Next: Java Exceptions, Prev: Namespace Association, Up: C++ Extensions
-
-6.9 Type Traits
-===============
-
-The C++ front-end implements syntactic extensions that allow to
-determine at compile time 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, an array type of unknown bound, or is a `void'
- type.
-
-`__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, an
- array type of unknown bound, or is a `void' type.
-
-`__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, an array type of unknown bound,
- or is a `void' type.
-
-`__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, an array type
- of unknown bound, or is a `void' type.
-
-`__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, an
- array type of unknown bound, or is a `void' type.
-
-`__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, an
- array type of unknown bound, or is a `void' type.
-
-`__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, an array type of unknown bound, or is a `void' type.
-
-`__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, an array type of unknown bound, or is a `void'
- type.
-
-`__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, an array type of unknown bound, or is a `void' type.
-
-`__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, an array type of
- unknown bound, or is a `void' type.
-
-`__is_enum (type)'
- If `type' is a cv enumeration type ([basic.compound]) the trait is
- true, else it is false.
-
-`__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, an
- array type of unknown bound, or is a `void' type.
-
-`__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, an array type of unknown bound, or is a `void' type.
-
-`__is_union (type)'
- If `type' is a cv union type ([basic.compound]) the trait is true,
- else it is false.
-
-
-\1f
-File: gcc.info, Node: Java Exceptions, Next: Deprecated Features, Prev: Type Traits, Up: C++ Extensions
-
-6.10 Java Exceptions
-====================
-
-The Java language uses a slightly different exception handling model
-from C++. Normally, GNU C++ 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 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.
-
-\1f
-File: gcc.info, Node: Deprecated Features, Next: Backwards Compatibility, Prev: Java Exceptions, Up: C++ Extensions
-
-6.11 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.
-
-\1f
-File: gcc.info, Node: Backwards Compatibility, Prev: Deprecated Features, Up: C++ Extensions
-
-6.12 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 which 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 `()' will be treated as an unspecified number of
- arguments, rather than no arguments, as C++ demands.
-
-\1f
-File: gcc.info, Node: Objective-C, Next: Compatibility, Prev: C++ Extensions, Up: Top
-
-7 GNU Objective-C runtime features
-**********************************
-
-This document is meant to describe some of the GNU Objective-C runtime
-features. It is not intended to teach you Objective-C, there are
-several resources on the Internet that present the language. Questions
-and comments about this document to Ovidiu Predescu <ovidiu@cup.hp.com>.
-
-* Menu:
-
-* Executing code before main::
-* Type encoding::
-* Garbage Collection::
-* Constant string objects::
-* compatibility_alias::
-
-\1f
-File: gcc.info, Node: Executing code before main, Next: Type encoding, Prev: Objective-C, Up: Objective-C
-
-7.1 `+load': Executing code before main
-=======================================
-
-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::
-
-\1f
-File: gcc.info, Node: What you can and what you cannot do in +load, Prev: Executing code before main, Up: Executing code before main
-
-7.1.1 What you can and what you cannot do in `+load'
-----------------------------------------------------
-
-The `+load' implementation in the GNU runtime guarantees you the
-following things:
-
- * you can write whatever C code you like;
-
- * you can send messages to Objective-C constant strings (`@"this is a
- constant string"');
-
- * 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;
-
-
- 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.
-
-\1f
-File: gcc.info, Node: Type encoding, Next: Garbage Collection, Prev: Executing code before main, Up: Objective-C
-
-7.2 Type encoding
-=================
-
-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'
-`void' `v'
-`id' `@'
-`Class' `#'
-`SEL' `:'
-`char*' `*'
-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 `)'
-
- 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;
- }
-
-
- 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'
-`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.
-
-\1f
-File: gcc.info, Node: Garbage Collection, Next: Constant string objects, Prev: Type encoding, Up: Objective-C
-
-7.3 Garbage Collection
-======================
-
-Support for a new memory management policy has been added by using a
-powerful conservative garbage collector, known as the
-Boehm-Demers-Weiser conservative garbage collector. It is available
-from `http://www.hpl.hp.com/personal/Hans_Boehm/gc/'.
-
- To enable the support for it you have to configure the compiler using
-an additional argument, `--enable-objc-gc'. You need to have garbage
-collector installed before building the compiler. This will 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
- {
- 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.
-
-\1f
-File: gcc.info, Node: Constant string objects, Next: compatibility_alias, Prev: Garbage Collection, Up: Objective-C
-
-7.4 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.
-
-\1f
-File: gcc.info, Node: compatibility_alias, Prev: Constant string objects, Up: Objective-C
-
-7.5 compatibility_alias
-=======================
-
-This is a feature of the Objective-C compiler rather than of the
-runtime, anyway since it is documented nowhere and its existence was
-forgotten, we are documenting it here.
-
- 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.
-
-
-\1f
-File: gcc.info, Node: Compatibility, Next: Gcov, Prev: Objective-C, Up: Top
-
-8 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'.
-
-\1f
-File: gcc.info, Node: Gcov, Next: Trouble, Prev: Compatibility, Up: Top
-
-9 `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.
-
-\1f
-File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov
-
-9.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.
-
-\1f
-File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov
-
-9.2 Invoking `gcov'
-===================
-
- gcov [OPTIONS] SOURCEFILES
-
- `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. 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 `..' components renamed to `^'. This is useful if
- sourcefiles are in several different directories. It also affects
- the `-l' option.
-
-`-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 source file
- name, without its extension. If a file is specified here, the
- data files are named after that file, without its extension. If
- this option is not supplied, it defaults to the current directory.
-
-`-u'
-`--unconditional-branches'
- When branch probabilities are given, include those of
- unconditional branches. Unconditional branches are normally not
- interesting.
-
-
- `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 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.
-
- 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 and `#####' for lines which were never executed. Some lines of
-information at the start have LINE_NUMBER of zero.
-
- The 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.
-
-\1f
-File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov
-
-9.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.
-
-\1f
-File: gcc.info, Node: Gcov Data Files, Next: Cross-profiling, Prev: Gcov and Optimization, Up: Gcov
-
-9.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'. All of these files are placed in the
-same directory as the object file, and contain data stored in a
-platform-independent format.
-
- The `.gcno' 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' 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, 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.
-
-\1f
-File: gcc.info, Node: Cross-profiling, Prev: Gcov Data Files, Up: Gcov
-
-9.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 must be absolute as well, otherwise its
- value is ignored. 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:_ GCOV_PREFIX_STRIP has no effect if GCOV_PREFIX is
- undefined, empty or non-absolute.
-
- 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.
-
-\1f
-File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top
-
-10 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.
-* Cross-Compiler Problems:: Common problems of cross compiling with GCC.
-* 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++.
-* Protoize Caveats:: Things to watch out for when using `protoize'.
-* 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.
-
-\1f
-File: gcc.info, Node: Actual Bugs, Next: Cross-Compiler Problems, Up: Trouble
-
-10.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.
-
- * The `fixproto' script will sometimes add prototypes for the
- `sigsetjmp' and `siglongjmp' functions that reference the
- `jmp_buf' type before that type is defined. To work around this,
- edit the offending file and place the typedef in front of the
- prototypes.
-
-\1f
-File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Actual Bugs, Up: Trouble
-
-10.2 Cross-Compiler Problems
-============================
-
-You may run into problems with cross compilation on certain machines,
-for several reasons.
-
- * At present, the program `mips-tfile' which adds debug support to
- object files on MIPS systems does not work in a cross compile
- environment.
-
-\1f
-File: gcc.info, Node: Interoperation, Next: Incompatibilities, Prev: Cross-Compiler Problems, Up: Trouble
-
-10.3 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 some SGI systems, when you use `-lgl_s' as an option, it gets
- translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this
- does not happen when you use GCC. You must specify all three
- options explicitly.
-
- * 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.
-
-
-\1f
-File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: Interoperation, Up: Trouble
-
-10.4 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, a `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 C89 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.
-
-\1f
-File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
-
-10.5 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.
-
-\1f
-File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble
-
-10.6 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.
-
-\1f
-File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble
-
-10.7 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.
-
-\1f
-File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble
-
-10.8 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
-
-\1f
-File: gcc.info, Node: Static Definitions, Next: Name lookup, Up: C++ Misunderstandings
-
-10.8.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.
-
-\1f
-File: gcc.info, Node: Name lookup, Next: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings
-
-10.8.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.
-
-\1f
-File: gcc.info, Node: Temporaries, Next: Copy Assignment, Prev: Name lookup, Up: C++ Misunderstandings
-
-10.8.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 ());
-
-\1f
-File: gcc.info, Node: Copy Assignment, Prev: Temporaries, Up: C++ Misunderstandings
-
-10.8.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.
-
-\1f
-File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble
-
-10.9 Caveats of using `protoize'
-================================
-
-The conversion programs `protoize' and `unprotoize' can sometimes
-change a source file in a way that won't work unless you rearrange it.
-
- * `protoize' can insert references to a type name or type tag before
- the definition, or in a file where they are not defined.
-
- If this happens, compiler error messages should show you where the
- new references are, so fixing the file by hand is straightforward.
-
- * There are some C constructs which `protoize' cannot figure out.
- For example, it can't determine argument types for declaring a
- pointer-to-function variable; this you must do by hand. `protoize'
- inserts a comment containing `???' each time it finds such a
- variable; so you can find all such variables by searching for this
- string. ISO C does not require declaring the argument types of
- pointer-to-function types.
-
- * Using `unprotoize' can easily introduce bugs. If the program
- relied on prototypes to bring about conversion of arguments, these
- conversions will not take place in the program without prototypes.
- One case in which you can be sure `unprotoize' is safe is when you
- are removing prototypes that were made with `protoize'; if the
- program worked before without any prototypes, it will work again
- without them.
-
- You can find all the places where this problem might occur by
- compiling the program with the `-Wtraditional-conversion' option.
- It prints a warning whenever an argument is converted.
-
- * Both conversion programs can be confused if there are macro calls
- in and around the text to be converted. In other words, the
- standard syntax for a declaration or definition must not result
- from expanding a macro. This problem is inherent in the design of
- C and cannot be fixed. If only a few functions have confusing
- macro calls, you can easily convert them manually.
-
- * `protoize' cannot get the argument types for a function whose
- definition was not actually compiled due to preprocessing
- conditionals. When this happens, `protoize' changes nothing in
- regard to such a function. `protoize' tries to detect such
- instances and warn about them.
-
- You can generally work around this problem by using `protoize' step
- by step, each time specifying a different set of `-D' options for
- compilation, until all of the functions have been converted.
- There is no automatic way to verify that you have got them all,
- however.
-
- * Confusion may result if there is an occasion to convert a function
- declaration or definition in a region of source code where there
- is more than one formal parameter list present. Thus, attempts to
- convert code containing multiple (conditionally compiled) versions
- of a single function header (in the same vicinity) may not produce
- the desired (or expected) results.
-
- If you plan on converting source files which contain such code, it
- is recommended that you first make sure that each conditionally
- compiled region of source code which contains an alternative
- function header also contains at least one additional follower
- token (past the final right parenthesis of the function header).
- This should circumvent the problem.
-
- * `unprotoize' can become confused when trying to convert a function
- definition or declaration which contains a declaration for a
- pointer-to-function formal argument which has the same name as the
- function being defined or declared. We recommend you avoid such
- choices of formal parameter names.
-
- * You might also want to correct some of the indentation by hand and
- break long lines. (The conversion programs don't write lines
- longer than eighty characters in any case.)
-
-\1f
-File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble
-
-10.10 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.
-
-
-\1f
-File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble
-
-10.11 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.
-
-\1f
-File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top
-
-11 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.
-* Known: Trouble. Known problems.
-* Help: Service. Where to ask for help.
-
-\1f
-File: gcc.info, Node: Bug Criteria, Next: Bug Reporting, Up: Bugs
-
-11.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.
-
-\1f
-File: gcc.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Bugs
-
-11.2 How and where to Report Bugs
-=================================
-
-Bugs should be reported to the bug database at
-`http://gcc.gnu.org/bugs.html'.
-
-\1f
-File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top
-
-12 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'.
-
-\1f
-File: gcc.info, Node: Contributing, Next: Funding, Prev: Service, Up: Top
-
-13 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/'.
-
-\1f
-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.
-
-\1f
-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'
-
-\1f
-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'.
-
-\1f
-File: gcc.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-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.
-
- * 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.
-
- * 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.
-
- * 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 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 port.
-
- * 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.
-
- * Zdenek Dvorak for a new loop unroller and various fixes.
-
- * 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
- continuously 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
- since the late 1980s.
-
- * 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 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.
-
- * 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.
-
- * 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.
-
- * 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.
-
- * 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 for GCC 3.x.
-
- * 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, etc.
-
- * 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.
-
- * 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 as well a serving as release manager for
- GCC 2.95.3.
-
- * 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.
-
- * 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.
-
- * 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'.
-
- * 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 his mips16 work, 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.
-
- * 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.
-
- * 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.
-
-\1f
-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.
-
-\0\b[index\0\b]
-* Menu:
-
-* ###: Overall Options. (line 204)
-* -fdump-statistics: Debugging Options. (line 611)
-* A: Preprocessor Options.
- (line 539)
-* all_load: Darwin Options. (line 112)
-* allowable_client: Darwin Options. (line 199)
-* ansi <1>: Non-bugs. (line 107)
-* ansi <2>: Other Builtins. (line 22)
-* ansi <3>: Preprocessor Options.
- (line 326)
-* ansi <4>: C Dialect Options. (line 11)
-* ansi: Standards. (line 16)
-* arch_errors_fatal: Darwin Options. (line 116)
-* aux-info: C Dialect Options. (line 140)
-* b: Target Options. (line 13)
-* B: Directory Options. (line 41)
-* bcopy-builtin: PDP-11 Options. (line 32)
-* Bdynamic: VxWorks Options. (line 22)
-* bind_at_load: Darwin Options. (line 120)
-* Bstatic: VxWorks Options. (line 22)
-* bundle: Darwin Options. (line 125)
-* bundle_loader: Darwin Options. (line 129)
-* c: Link Options. (line 20)
-* C: Preprocessor Options.
- (line 597)
-* c: Overall Options. (line 159)
-* client_name: Darwin Options. (line 199)
-* combine: Overall Options. (line 215)
-* compatibility_version: Darwin Options. (line 199)
-* coverage: Debugging Options. (line 264)
-* current_version: Darwin Options. (line 199)
-* D: Preprocessor Options.
- (line 34)
-* d: Debugging Options. (line 328)
-* dA: Debugging Options. (line 530)
-* dD <1>: Preprocessor Options.
- (line 571)
-* dD: Debugging Options. (line 534)
-* dead_strip: Darwin Options. (line 199)
-* dependency-file: Darwin Options. (line 199)
-* dH: Debugging Options. (line 538)
-* dI: Preprocessor Options.
- (line 580)
-* dM: Preprocessor Options.
- (line 555)
-* dm: Debugging Options. (line 541)
-* dN: Preprocessor Options.
- (line 577)
-* dP: Debugging Options. (line 550)
-* dp: Debugging Options. (line 545)
-* dU: Preprocessor Options.
- (line 584)
-* dumpmachine: Debugging Options. (line 938)
-* dumpspecs: Debugging Options. (line 946)
-* dumpversion: Debugging Options. (line 942)
-* dv: Debugging Options. (line 554)
-* dx: Debugging Options. (line 559)
-* dy: Debugging Options. (line 563)
-* dylib_file: Darwin Options. (line 199)
-* dylinker_install_name: Darwin Options. (line 199)
-* dynamic: Darwin Options. (line 199)
-* dynamiclib: Darwin Options. (line 133)
-* E <1>: Link Options. (line 20)
-* E: Overall Options. (line 180)
-* EB <1>: MIPS Options. (line 7)
-* EB: ARC Options. (line 12)
-* EL <1>: MIPS Options. (line 10)
-* EL: ARC Options. (line 9)
-* exported_symbols_list: Darwin Options. (line 199)
-* F: Darwin Options. (line 32)
-* fabi-version: C++ Dialect Options.
- (line 20)
-* falign-functions: Optimize Options. (line 1184)
-* falign-jumps: Optimize Options. (line 1234)
-* falign-labels: Optimize Options. (line 1202)
-* falign-loops: Optimize Options. (line 1220)
-* fargument-alias: Code Gen Options. (line 413)
-* fargument-noalias: Code Gen Options. (line 413)
-* fargument-noalias-anything: Code Gen Options. (line 413)
-* fargument-noalias-global: Code Gen Options. (line 413)
-* fassociative-math: Optimize Options. (line 1411)
-* fasynchronous-unwind-tables: Code Gen Options. (line 64)
-* fauto-inc-dec: Optimize Options. (line 455)
-* fbounds-check: Code Gen Options. (line 15)
-* fbranch-probabilities: Optimize Options. (line 1544)
-* fbranch-target-load-optimize: Optimize Options. (line 1652)
-* fbranch-target-load-optimize2: Optimize Options. (line 1658)
-* fbtr-bb-exclusive: Optimize Options. (line 1662)
-* fcall-saved: Code Gen Options. (line 262)
-* fcall-used: Code Gen Options. (line 248)
-* fcaller-saves: Optimize Options. (line 676)
-* fcheck-data-deps: Optimize Options. (line 897)
-* fcheck-new: C++ Dialect Options.
- (line 34)
-* fcommon: Variable Attributes.
- (line 105)
-* fcond-mismatch: C Dialect Options. (line 258)
-* fconserve-space: C++ Dialect Options.
- (line 44)
-* fconserve-stack: Optimize Options. (line 689)
-* fconstant-string-class: Objective-C and Objective-C++ Dialect Options.
- (line 30)
-* fcprop-registers: Optimize Options. (line 1292)
-* fcrossjumping: Optimize Options. (line 448)
-* fcse-follow-jumps: Optimize Options. (line 376)
-* fcse-skip-blocks: Optimize Options. (line 385)
-* fcx-fortran-rules: Optimize Options. (line 1530)
-* fcx-limited-range: Optimize Options. (line 1518)
-* fdata-sections: Optimize Options. (line 1633)
-* fdbg-cnt: Debugging Options. (line 317)
-* fdbg-cnt-list: Debugging Options. (line 314)
-* fdce: Optimize Options. (line 461)
-* fdebug-prefix-map: Debugging Options. (line 211)
-* fdelayed-branch: Optimize Options. (line 557)
-* fdelete-null-pointer-checks: Optimize Options. (line 484)
-* fdiagnostics-show-location: Language Independent Options.
- (line 21)
-* fdiagnostics-show-option: Language Independent Options.
- (line 36)
-* fdirectives-only: Preprocessor Options.
- (line 447)
-* fdollars-in-identifiers <1>: Interoperation. (line 146)
-* fdollars-in-identifiers: Preprocessor Options.
- (line 469)
-* fdse: Optimize Options. (line 465)
-* fdump-class-hierarchy: Debugging Options. (line 587)
-* fdump-ipa: Debugging Options. (line 594)
-* fdump-noaddr: Debugging Options. (line 566)
-* fdump-rtl-alignments: Debugging Options. (line 342)
-* fdump-rtl-all: Debugging Options. (line 527)
-* fdump-rtl-asmcons: Debugging Options. (line 345)
-* fdump-rtl-auto_inc_dec: Debugging Options. (line 349)
-* fdump-rtl-barriers: Debugging Options. (line 353)
-* fdump-rtl-bbpart: Debugging Options. (line 356)
-* fdump-rtl-bbro: Debugging Options. (line 359)
-* fdump-rtl-btl2: Debugging Options. (line 363)
-* fdump-rtl-bypass: Debugging Options. (line 367)
-* fdump-rtl-ce1: Debugging Options. (line 378)
-* fdump-rtl-ce2: Debugging Options. (line 378)
-* fdump-rtl-ce3: Debugging Options. (line 378)
-* fdump-rtl-combine: Debugging Options. (line 370)
-* fdump-rtl-compgotos: Debugging Options. (line 373)
-* fdump-rtl-cprop_hardreg: Debugging Options. (line 382)
-* fdump-rtl-csa: Debugging Options. (line 385)
-* fdump-rtl-cse1: Debugging Options. (line 389)
-* fdump-rtl-cse2: Debugging Options. (line 389)
-* fdump-rtl-dbr: Debugging Options. (line 396)
-* fdump-rtl-dce: Debugging Options. (line 393)
-* fdump-rtl-dce1: Debugging Options. (line 400)
-* fdump-rtl-dce2: Debugging Options. (line 400)
-* fdump-rtl-dfinish: Debugging Options. (line 524)
-* fdump-rtl-dfinit: Debugging Options. (line 524)
-* fdump-rtl-eh: Debugging Options. (line 404)
-* fdump-rtl-eh_ranges: Debugging Options. (line 407)
-* fdump-rtl-expand: Debugging Options. (line 410)
-* fdump-rtl-fwprop1: Debugging Options. (line 414)
-* fdump-rtl-fwprop2: Debugging Options. (line 414)
-* fdump-rtl-gcse1: Debugging Options. (line 419)
-* fdump-rtl-gcse2: Debugging Options. (line 419)
-* fdump-rtl-init-regs: Debugging Options. (line 423)
-* fdump-rtl-initvals: Debugging Options. (line 426)
-* fdump-rtl-into_cfglayout: Debugging Options. (line 429)
-* fdump-rtl-ira: Debugging Options. (line 432)
-* fdump-rtl-jump: Debugging Options. (line 435)
-* fdump-rtl-loop2: Debugging Options. (line 438)
-* fdump-rtl-mach: Debugging Options. (line 442)
-* fdump-rtl-mode_sw: Debugging Options. (line 446)
-* fdump-rtl-outof_cfglayout: Debugging Options. (line 452)
-* fdump-rtl-peephole2: Debugging Options. (line 455)
-* fdump-rtl-postreload: Debugging Options. (line 458)
-* fdump-rtl-pro_and_epilogue: Debugging Options. (line 461)
-* fdump-rtl-regclass: Debugging Options. (line 524)
-* fdump-rtl-regmove: Debugging Options. (line 464)
-* fdump-rtl-rnreg: Debugging Options. (line 449)
-* fdump-rtl-sched1: Debugging Options. (line 468)
-* fdump-rtl-sched2: Debugging Options. (line 468)
-* fdump-rtl-see: Debugging Options. (line 472)
-* fdump-rtl-seqabstr: Debugging Options. (line 475)
-* fdump-rtl-shorten: Debugging Options. (line 478)
-* fdump-rtl-sibling: Debugging Options. (line 481)
-* fdump-rtl-sms: Debugging Options. (line 494)
-* fdump-rtl-split1: Debugging Options. (line 488)
-* fdump-rtl-split2: Debugging Options. (line 488)
-* fdump-rtl-split3: Debugging Options. (line 488)
-* fdump-rtl-split4: Debugging Options. (line 488)
-* fdump-rtl-split5: Debugging Options. (line 488)
-* fdump-rtl-stack: Debugging Options. (line 498)
-* fdump-rtl-subreg1: Debugging Options. (line 504)
-* fdump-rtl-subreg2: Debugging Options. (line 504)
-* fdump-rtl-subregs_of_mode_finish: Debugging Options. (line 524)
-* fdump-rtl-subregs_of_mode_init: Debugging Options. (line 524)
-* fdump-rtl-unshare: Debugging Options. (line 508)
-* fdump-rtl-vartrack: Debugging Options. (line 511)
-* fdump-rtl-vregs: Debugging Options. (line 514)
-* fdump-rtl-web: Debugging Options. (line 517)
-* fdump-translation-unit: Debugging Options. (line 579)
-* fdump-tree: Debugging Options. (line 621)
-* fdump-tree-alias: Debugging Options. (line 705)
-* fdump-tree-all: Debugging Options. (line 790)
-* fdump-tree-ccp: Debugging Options. (line 709)
-* fdump-tree-cfg: Debugging Options. (line 685)
-* fdump-tree-ch: Debugging Options. (line 697)
-* fdump-tree-copyprop: Debugging Options. (line 725)
-* fdump-tree-copyrename: Debugging Options. (line 771)
-* fdump-tree-dce: Debugging Options. (line 733)
-* fdump-tree-dom: Debugging Options. (line 751)
-* fdump-tree-dse: Debugging Options. (line 756)
-* fdump-tree-forwprop: Debugging Options. (line 766)
-* fdump-tree-fre: Debugging Options. (line 721)
-* fdump-tree-gimple: Debugging Options. (line 680)
-* fdump-tree-mudflap: Debugging Options. (line 737)
-* fdump-tree-nrv: Debugging Options. (line 776)
-* fdump-tree-phiopt: Debugging Options. (line 761)
-* fdump-tree-pre: Debugging Options. (line 717)
-* fdump-tree-sink: Debugging Options. (line 747)
-* fdump-tree-sra: Debugging Options. (line 742)
-* fdump-tree-ssa: Debugging Options. (line 701)
-* fdump-tree-store_copyprop: Debugging Options. (line 729)
-* fdump-tree-storeccp: Debugging Options. (line 713)
-* fdump-tree-vcg: Debugging Options. (line 689)
-* fdump-tree-vect: Debugging Options. (line 781)
-* fdump-tree-vrp: Debugging Options. (line 786)
-* fdump-unnumbered: Debugging Options. (line 572)
-* fdwarf2-cfi-asm: Debugging Options. (line 215)
-* fearly-inlining: Optimize Options. (line 220)
-* feliminate-dwarf2-dups: Debugging Options. (line 128)
-* feliminate-unused-debug-symbols: Debugging Options. (line 52)
-* feliminate-unused-debug-types: Debugging Options. (line 950)
-* fexceptions: Code Gen Options. (line 34)
-* fexec-charset: Preprocessor Options.
- (line 496)
-* fexpensive-optimizations: Optimize Options. (line 497)
-* fextended-identifiers: Preprocessor Options.
- (line 472)
-* ffast-math: Optimize Options. (line 1362)
-* ffinite-math-only: Optimize Options. (line 1435)
-* ffix-and-continue: Darwin Options. (line 106)
-* ffixed: Code Gen Options. (line 236)
-* ffloat-store <1>: Disappointments. (line 77)
-* ffloat-store: Optimize Options. (line 1348)
-* ffor-scope: C++ Dialect Options.
- (line 104)
-* fforward-propagate: Optimize Options. (line 149)
-* ffreestanding <1>: Function Attributes.
- (line 412)
-* ffreestanding <2>: Warning Options. (line 194)
-* ffreestanding <3>: C Dialect Options. (line 211)
-* ffreestanding: Standards. (line 84)
-* ffriend-injection: C++ Dialect Options.
- (line 74)
-* ffunction-sections: Optimize Options. (line 1633)
-* fgcse: Optimize Options. (line 399)
-* fgcse-after-reload: Optimize Options. (line 435)
-* fgcse-las: Optimize Options. (line 428)
-* fgcse-lm: Optimize Options. (line 410)
-* fgcse-sm: Optimize Options. (line 419)
-* fgnu-runtime: Objective-C and Objective-C++ Dialect Options.
- (line 39)
-* fgnu89-inline: C Dialect Options. (line 120)
-* fhosted: C Dialect Options. (line 204)
-* fif-conversion: Optimize Options. (line 469)
-* fif-conversion2: Optimize Options. (line 478)
-* filelist: Darwin Options. (line 199)
-* findirect-data: Darwin Options. (line 106)
-* findirect-inlining: Optimize Options. (line 193)
-* finhibit-size-directive: Code Gen Options. (line 158)
-* finline-functions: Optimize Options. (line 201)
-* finline-functions-called-once: Optimize Options. (line 212)
-* finline-limit: Optimize Options. (line 230)
-* finline-small-functions: Optimize Options. (line 185)
-* finput-charset: Preprocessor Options.
- (line 509)
-* finstrument-functions <1>: Function Attributes.
- (line 712)
-* finstrument-functions: Code Gen Options. (line 292)
-* finstrument-functions-exclude-file-list: Code Gen Options. (line 329)
-* finstrument-functions-exclude-function-list: Code Gen Options.
- (line 347)
-* fipa-cp: Optimize Options. (line 742)
-* fipa-cp-clone: Optimize Options. (line 750)
-* fipa-matrix-reorg: Optimize Options. (line 760)
-* fipa-pta: Optimize Options. (line 738)
-* fipa-pure-const: Optimize Options. (line 715)
-* fipa-reference: Optimize Options. (line 719)
-* fipa-struct-reorg: Optimize Options. (line 723)
-* fira-coalesce: Optimize Options. (line 536)
-* fira-verbose: Optimize Options. (line 552)
-* fivopts: Optimize Options. (line 933)
-* fkeep-inline-functions <1>: Inline. (line 51)
-* fkeep-inline-functions: Optimize Options. (line 256)
-* fkeep-static-consts: Optimize Options. (line 263)
-* flat_namespace: Darwin Options. (line 199)
-* flax-vector-conversions: C Dialect Options. (line 263)
-* fleading-underscore: Code Gen Options. (line 430)
-* fmem-report: Debugging Options. (line 239)
-* fmerge-all-constants: Optimize Options. (line 282)
-* fmerge-constants: Optimize Options. (line 272)
-* fmerge-debug-strings: Debugging Options. (line 203)
-* fmessage-length: Language Independent Options.
- (line 15)
-* fmodulo-sched: Optimize Options. (line 293)
-* fmodulo-sched-allow-regmoves: Optimize Options. (line 298)
-* fmove-loop-invariants: Optimize Options. (line 1623)
-* fms-extensions <1>: Unnamed Fields. (line 37)
-* fms-extensions <2>: C++ Dialect Options.
- (line 139)
-* fms-extensions: C Dialect Options. (line 229)
-* fmudflap: Optimize Options. (line 338)
-* fmudflapir: Optimize Options. (line 338)
-* fmudflapth: Optimize Options. (line 338)
-* fnext-runtime: Objective-C and Objective-C++ Dialect Options.
- (line 43)
-* fno-access-control: C++ Dialect Options.
- (line 30)
-* fno-asm: C Dialect Options. (line 156)
-* fno-branch-count-reg: Optimize Options. (line 305)
-* fno-builtin <1>: Other Builtins. (line 14)
-* fno-builtin <2>: Function Attributes.
- (line 412)
-* fno-builtin <3>: Warning Options. (line 194)
-* fno-builtin: C Dialect Options. (line 170)
-* fno-common <1>: Variable Attributes.
- (line 105)
-* fno-common: Code Gen Options. (line 135)
-* fno-deduce-init-list: C++ Dialect Options.
- (line 56)
-* fno-default-inline <1>: Inline. (line 71)
-* fno-default-inline <2>: Optimize Options. (line 134)
-* fno-default-inline: C++ Dialect Options.
- (line 280)
-* fno-defer-pop: Optimize Options. (line 141)
-* fno-dwarf2-cfi-asm: Debugging Options. (line 215)
-* fno-elide-constructors: C++ Dialect Options.
- (line 87)
-* fno-enforce-eh-specs: C++ Dialect Options.
- (line 93)
-* fno-for-scope: C++ Dialect Options.
- (line 104)
-* fno-function-cse: Optimize Options. (line 315)
-* fno-gnu-keywords: C++ Dialect Options.
- (line 116)
-* fno-guess-branch-probability: Optimize Options. (line 1056)
-* fno-ident: Code Gen Options. (line 155)
-* fno-implement-inlines <1>: C++ Interface. (line 75)
-* fno-implement-inlines: C++ Dialect Options.
- (line 133)
-* fno-implicit-inline-templates: C++ Dialect Options.
- (line 127)
-* fno-implicit-templates <1>: Template Instantiation.
- (line 87)
-* fno-implicit-templates: C++ Dialect Options.
- (line 121)
-* fno-inline: Optimize Options. (line 179)
-* fno-ira-share-save-slots: Optimize Options. (line 540)
-* fno-ira-share-spill-slots: Optimize Options. (line 546)
-* fno-jump-tables: Code Gen Options. (line 228)
-* fno-math-errno: Optimize Options. (line 1376)
-* fno-merge-debug-strings: Debugging Options. (line 203)
-* fno-nil-receivers: Objective-C and Objective-C++ Dialect Options.
- (line 49)
-* fno-nonansi-builtins: C++ Dialect Options.
- (line 144)
-* fno-operator-names: C++ Dialect Options.
- (line 149)
-* fno-optional-diags: C++ Dialect Options.
- (line 153)
-* fno-peephole: Optimize Options. (line 1047)
-* fno-peephole2: Optimize Options. (line 1047)
-* fno-rtti: C++ Dialect Options.
- (line 168)
-* fno-sched-interblock: Optimize Options. (line 583)
-* fno-sched-spec: Optimize Options. (line 588)
-* fno-show-column: Preprocessor Options.
- (line 534)
-* fno-signed-bitfields: C Dialect Options. (line 296)
-* fno-signed-zeros: Optimize Options. (line 1447)
-* fno-stack-limit: Code Gen Options. (line 396)
-* fno-threadsafe-statics: C++ Dialect Options.
- (line 190)
-* fno-toplevel-reorder: Optimize Options. (line 1254)
-* fno-trapping-math: Optimize Options. (line 1457)
-* fno-unsigned-bitfields: C Dialect Options. (line 296)
-* fno-use-cxa-get-exception-ptr: C++ Dialect Options.
- (line 203)
-* fno-weak: C++ Dialect Options.
- (line 265)
-* fno-working-directory: Preprocessor Options.
- (line 519)
-* fno-zero-initialized-in-bss: Optimize Options. (line 326)
-* fnon-call-exceptions: Code Gen Options. (line 48)
-* fobjc-call-cxx-cdtors: Objective-C and Objective-C++ Dialect Options.
- (line 56)
-* fobjc-direct-dispatch: Objective-C and Objective-C++ Dialect Options.
- (line 81)
-* fobjc-exceptions: Objective-C and Objective-C++ Dialect Options.
- (line 85)
-* fobjc-gc: Objective-C and Objective-C++ Dialect Options.
- (line 170)
-* fomit-frame-pointer: Optimize Options. (line 158)
-* fopenmp: C Dialect Options. (line 221)
-* foptimize-register-move: Optimize Options. (line 504)
-* foptimize-sibling-calls: Optimize Options. (line 174)
-* force_cpusubtype_ALL: Darwin Options. (line 138)
-* force_flat_namespace: Darwin Options. (line 199)
-* fpack-struct: Code Gen Options. (line 279)
-* fpcc-struct-return <1>: Incompatibilities. (line 170)
-* fpcc-struct-return: Code Gen Options. (line 70)
-* fpch-deps: Preprocessor Options.
- (line 282)
-* fpch-preprocess: Preprocessor Options.
- (line 290)
-* fpeel-loops: Optimize Options. (line 1615)
-* fpermissive: C++ Dialect Options.
- (line 158)
-* fPIC: Code Gen Options. (line 205)
-* fpic: Code Gen Options. (line 184)
-* fPIE: Code Gen Options. (line 218)
-* fpie: Code Gen Options. (line 218)
-* fpost-ipa-mem-report: Debugging Options. (line 245)
-* fpre-ipa-mem-report: Debugging Options. (line 243)
-* fpredictive-commoning: Optimize Options. (line 1029)
-* fprefetch-loop-arrays: Optimize Options. (line 1036)
-* fpreprocessed: Preprocessor Options.
- (line 477)
-* fprofile-arcs <1>: Other Builtins. (line 242)
-* fprofile-arcs: Debugging Options. (line 249)
-* fprofile-correction: Optimize Options. (line 1299)
-* fprofile-dir: Optimize Options. (line 1306)
-* fprofile-generate: Optimize Options. (line 1316)
-* fprofile-use: Optimize Options. (line 1329)
-* fprofile-values: Optimize Options. (line 1563)
-* frandom-string: Debugging Options. (line 819)
-* freciprocal-math: Optimize Options. (line 1426)
-* frecord-gcc-switches: Code Gen Options. (line 174)
-* freg-struct-return: Code Gen Options. (line 88)
-* fregmove: Optimize Options. (line 504)
-* frename-registers: Optimize Options. (line 1582)
-* freorder-blocks: Optimize Options. (line 1073)
-* freorder-blocks-and-partition: Optimize Options. (line 1079)
-* freorder-functions: Optimize Options. (line 1090)
-* freplace-objc-classes: Objective-C and Objective-C++ Dialect Options.
- (line 174)
-* frepo <1>: Template Instantiation.
- (line 62)
-* frepo: C++ Dialect Options.
- (line 163)
-* frerun-cse-after-loop: Optimize Options. (line 393)
-* freschedule-modulo-scheduled-loops: Optimize Options. (line 652)
-* frounding-math: Optimize Options. (line 1472)
-* frtl-abstract-sequences: Optimize Options. (line 1492)
-* fsched-spec-load: Optimize Options. (line 593)
-* fsched-spec-load-dangerous: Optimize Options. (line 598)
-* fsched-stalled-insns: Optimize Options. (line 604)
-* fsched-stalled-insns-dep: Optimize Options. (line 614)
-* fsched-verbose: Debugging Options. (line 829)
-* fsched2-use-superblocks: Optimize Options. (line 624)
-* fsched2-use-traces: Optimize Options. (line 635)
-* fschedule-insns: Optimize Options. (line 564)
-* fschedule-insns2: Optimize Options. (line 574)
-* fsection-anchors: Optimize Options. (line 1678)
-* fsee: Optimize Options. (line 647)
-* fsel-sched-pipelining: Optimize Options. (line 666)
-* fsel-sched-pipelining-outer-loops: Optimize Options. (line 671)
-* fselective-scheduling: Optimize Options. (line 658)
-* fselective-scheduling2: Optimize Options. (line 662)
-* fshort-double: Code Gen Options. (line 117)
-* fshort-enums <1>: Non-bugs. (line 42)
-* fshort-enums <2>: Type Attributes. (line 113)
-* fshort-enums <3>: Structures unions enumerations and bit-fields implementation.
- (line 43)
-* fshort-enums: Code Gen Options. (line 106)
-* fshort-wchar: Code Gen Options. (line 125)
-* fsignaling-nans: Optimize Options. (line 1499)
-* fsigned-bitfields <1>: Non-bugs. (line 57)
-* fsigned-bitfields: C Dialect Options. (line 296)
-* fsigned-char <1>: Characters implementation.
- (line 31)
-* fsigned-char: C Dialect Options. (line 286)
-* fsingle-precision-constant: Optimize Options. (line 1514)
-* fsplit-ivs-in-unroller: Optimize Options. (line 1010)
-* fsplit-wide-types: Optimize Options. (line 368)
-* fstack-check: Code Gen Options. (line 357)
-* fstack-limit-register: Code Gen Options. (line 396)
-* fstack-limit-symbol: Code Gen Options. (line 396)
-* fstack-protector: Optimize Options. (line 1666)
-* fstack-protector-all: Optimize Options. (line 1675)
-* fstats: C++ Dialect Options.
- (line 178)
-* fstrict-aliasing: Optimize Options. (line 1103)
-* fstrict-overflow: Optimize Options. (line 1149)
-* fsyntax-only: Warning Options. (line 14)
-* ftabstop: Preprocessor Options.
- (line 490)
-* ftemplate-depth: C++ Dialect Options.
- (line 183)
-* ftest-coverage: Debugging Options. (line 305)
-* fthread-jumps: Optimize Options. (line 359)
-* ftime-report: Debugging Options. (line 235)
-* ftls-model: Code Gen Options. (line 441)
-* ftracer: Optimize Options. (line 993)
-* ftrapv: Code Gen Options. (line 22)
-* ftree-builtin-call-dce: Optimize Options. (line 788)
-* ftree-ccp: Optimize Options. (line 774)
-* ftree-ch: Optimize Options. (line 808)
-* ftree-copy-prop: Optimize Options. (line 710)
-* ftree-copyrename: Optimize Options. (line 953)
-* ftree-dce: Optimize Options. (line 784)
-* ftree-dominator-opts: Optimize Options. (line 794)
-* ftree-dse: Optimize Options. (line 801)
-* ftree-fre: Optimize Options. (line 703)
-* ftree-loop-im: Optimize Options. (line 918)
-* ftree-loop-ivcanon: Optimize Options. (line 927)
-* ftree-loop-linear: Optimize Options. (line 819)
-* ftree-loop-optimize: Optimize Options. (line 815)
-* ftree-parallelize-loops: Optimize Options. (line 938)
-* ftree-pre: Optimize Options. (line 699)
-* ftree-reassoc: Optimize Options. (line 695)
-* ftree-sink: Optimize Options. (line 770)
-* ftree-sra: Optimize Options. (line 947)
-* ftree-ter: Optimize Options. (line 960)
-* ftree-vect-loop-version: Optimize Options. (line 972)
-* ftree-vectorize: Optimize Options. (line 968)
-* ftree-vectorizer-verbose: Debugging Options. (line 794)
-* ftree-vrp: Optimize Options. (line 984)
-* funit-at-a-time: Optimize Options. (line 1247)
-* funroll-all-loops: Optimize Options. (line 1004)
-* funroll-loops: Optimize Options. (line 998)
-* funsafe-loop-optimizations: Optimize Options. (line 440)
-* funsafe-math-optimizations: Optimize Options. (line 1394)
-* funsigned-bitfields <1>: Non-bugs. (line 57)
-* funsigned-bitfields <2>: Structures unions enumerations and bit-fields implementation.
- (line 17)
-* funsigned-bitfields: C Dialect Options. (line 296)
-* funsigned-char <1>: Characters implementation.
- (line 31)
-* funsigned-char: C Dialect Options. (line 268)
-* funswitch-loops: Optimize Options. (line 1627)
-* funwind-tables: Code Gen Options. (line 57)
-* fuse-cxa-atexit: C++ Dialect Options.
- (line 196)
-* fvar-tracking: Debugging Options. (line 874)
-* fvariable-expansion-in-unroller: Optimize Options. (line 1024)
-* fvect-cost-model: Optimize Options. (line 981)
-* fverbose-asm: Code Gen Options. (line 165)
-* fvisibility: Code Gen Options. (line 449)
-* fvisibility-inlines-hidden: C++ Dialect Options.
- (line 208)
-* fvisibility-ms-compat: C++ Dialect Options.
- (line 236)
-* fvpt: Optimize Options. (line 1573)
-* fweb: Optimize Options. (line 1266)
-* fwhole-program: Optimize Options. (line 1277)
-* fwide-exec-charset: Preprocessor Options.
- (line 501)
-* fworking-directory: Preprocessor Options.
- (line 519)
-* fwrapv: Code Gen Options. (line 26)
-* fzero-link: Objective-C and Objective-C++ Dialect Options.
- (line 184)
-* G <1>: System V Options. (line 10)
-* G <2>: RS/6000 and PowerPC Options.
- (line 663)
-* G <3>: MIPS Options. (line 314)
-* G: M32R/D Options. (line 57)
-* g: Debugging Options. (line 10)
-* gcoff: Debugging Options. (line 70)
-* gdwarf-2: Debugging Options. (line 88)
-* gen-decls: Objective-C and Objective-C++ Dialect Options.
- (line 194)
-* gfull: Darwin Options. (line 71)
-* ggdb: Debugging Options. (line 38)
-* gnu-ld: HPPA Options. (line 111)
-* gstabs: Debugging Options. (line 44)
-* gstabs+: Debugging Options. (line 64)
-* gused: Darwin Options. (line 66)
-* gvms: Debugging Options. (line 95)
-* gxcoff: Debugging Options. (line 75)
-* gxcoff+: Debugging Options. (line 80)
-* H: Preprocessor Options.
- (line 652)
-* headerpad_max_install_names: Darwin Options. (line 199)
-* help <1>: Preprocessor Options.
- (line 644)
-* help: Overall Options. (line 231)
-* hp-ld: HPPA Options. (line 123)
-* I <1>: Directory Options. (line 10)
-* I: Preprocessor Options.
- (line 65)
-* I- <1>: Directory Options. (line 107)
-* I-: Preprocessor Options.
- (line 363)
-* idirafter: Preprocessor Options.
- (line 405)
-* iframework: Darwin Options. (line 59)
-* imacros: Preprocessor Options.
- (line 396)
-* image_base: Darwin Options. (line 199)
-* imultilib: Preprocessor Options.
- (line 428)
-* include: Preprocessor Options.
- (line 385)
-* init: Darwin Options. (line 199)
-* install_name: Darwin Options. (line 199)
-* iprefix: Preprocessor Options.
- (line 412)
-* iquote <1>: Directory Options. (line 31)
-* iquote: Preprocessor Options.
- (line 440)
-* isysroot: Preprocessor Options.
- (line 424)
-* isystem: Preprocessor Options.
- (line 432)
-* iwithprefix: Preprocessor Options.
- (line 418)
-* iwithprefixbefore: Preprocessor Options.
- (line 418)
-* keep_private_externs: Darwin Options. (line 199)
-* L: Directory Options. (line 37)
-* l: Link Options. (line 26)
-* lobjc: Link Options. (line 53)
-* M: Preprocessor Options.
- (line 173)
-* m1: SH Options. (line 9)
-* m10: PDP-11 Options. (line 29)
-* m128bit-long-double: i386 and x86-64 Options.
- (line 265)
-* m16-bit: CRIS Options. (line 64)
-* m2: SH Options. (line 12)
-* m210: MCore Options. (line 43)
-* m3: SH Options. (line 18)
-* m31: S/390 and zSeries Options.
- (line 87)
-* m32 <1>: SPARC Options. (line 191)
-* m32 <2>: RS/6000 and PowerPC Options.
- (line 252)
-* m32: i386 and x86-64 Options.
- (line 607)
-* m32-bit: CRIS Options. (line 64)
-* 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 435)
-* m3e: SH Options. (line 21)
-* m4: SH Options. (line 35)
-* m4-nofpu: SH Options. (line 24)
-* m4-single: SH Options. (line 31)
-* m4-single-only: SH Options. (line 27)
-* m40: PDP-11 Options. (line 23)
-* m45: PDP-11 Options. (line 26)
-* m4a: SH Options. (line 50)
-* m4a-nofpu: SH Options. (line 38)
-* m4a-single: SH Options. (line 46)
-* m4a-single-only: SH Options. (line 42)
-* m4al: SH Options. (line 53)
-* m4byte-functions: MCore Options. (line 27)
-* m5200: M680x0 Options. (line 143)
-* m5206e: M680x0 Options. (line 152)
-* m528x: M680x0 Options. (line 156)
-* m5307: M680x0 Options. (line 160)
-* m5407: M680x0 Options. (line 164)
-* m64 <1>: SPARC Options. (line 191)
-* m64 <2>: S/390 and zSeries Options.
- (line 87)
-* m64 <3>: RS/6000 and PowerPC Options.
- (line 252)
-* m64: i386 and x86-64 Options.
- (line 607)
-* m68000: M680x0 Options. (line 91)
-* m68010: M680x0 Options. (line 99)
-* m68020: M680x0 Options. (line 105)
-* m68020-40: M680x0 Options. (line 174)
-* m68020-60: M680x0 Options. (line 183)
-* m68030: M680x0 Options. (line 110)
-* m68040: M680x0 Options. (line 115)
-* m68060: M680x0 Options. (line 124)
-* m6811: M68hc1x Options. (line 13)
-* m6812: M68hc1x Options. (line 18)
-* m68881: M680x0 Options. (line 193)
-* m68hc11: M68hc1x Options. (line 13)
-* m68hc12: M68hc1x Options. (line 18)
-* m68hcs12: M68hc1x Options. (line 23)
-* m68S12: M68hc1x Options. (line 23)
-* m8-bit: CRIS Options. (line 64)
-* m96bit-long-double: i386 and x86-64 Options.
- (line 265)
-* mabi <1>: RS/6000 and PowerPC Options.
- (line 549)
-* mabi: ARM Options. (line 10)
-* mabi-mmixware: MMIX Options. (line 20)
-* mabi=32: MIPS Options. (line 129)
-* mabi=64: MIPS Options. (line 129)
-* mabi=eabi: MIPS Options. (line 129)
-* mabi=gnu: MMIX Options. (line 20)
-* mabi=ibmlongdouble: RS/6000 and PowerPC Options.
- (line 562)
-* mabi=ieeelongdouble: RS/6000 and PowerPC Options.
- (line 566)
-* mabi=n32: MIPS Options. (line 129)
-* mabi=no-spe: RS/6000 and PowerPC Options.
- (line 559)
-* mabi=o64: MIPS Options. (line 129)
-* mabi=spe: RS/6000 and PowerPC Options.
- (line 554)
-* mabicalls: MIPS Options. (line 153)
-* mabort-on-noreturn: ARM Options. (line 149)
-* mabshi: PDP-11 Options. (line 55)
-* mac0: PDP-11 Options. (line 16)
-* macc-4: FRV Options. (line 113)
-* macc-8: FRV Options. (line 116)
-* maccumulate-outgoing-args: i386 and x86-64 Options.
- (line 532)
-* madjust-unroll: SH Options. (line 196)
-* mads: RS/6000 and PowerPC Options.
- (line 592)
-* maix-struct-return: RS/6000 and PowerPC Options.
- (line 542)
-* maix32: RS/6000 and PowerPC Options.
- (line 290)
-* maix64: RS/6000 and PowerPC Options.
- (line 290)
-* malign-300: H8/300 Options. (line 31)
-* malign-double: i386 and x86-64 Options.
- (line 249)
-* malign-int: M680x0 Options. (line 263)
-* malign-labels: FRV Options. (line 104)
-* malign-loops: M32R/D Options. (line 73)
-* malign-natural: RS/6000 and PowerPC Options.
- (line 329)
-* malign-power: RS/6000 and PowerPC Options.
- (line 329)
-* malloc-cc: FRV Options. (line 25)
-* malpha-as: DEC Alpha Options. (line 159)
-* maltivec: RS/6000 and PowerPC Options.
- (line 183)
-* mam33: MN10300 Options. (line 17)
-* mapcs: ARM Options. (line 22)
-* mapcs-frame: ARM Options. (line 14)
-* mapp-regs <1>: V850 Options. (line 57)
-* mapp-regs: SPARC Options. (line 10)
-* march <1>: S/390 and zSeries Options.
- (line 116)
-* march <2>: MIPS Options. (line 14)
-* march <3>: M680x0 Options. (line 12)
-* march <4>: i386 and x86-64 Options.
- (line 148)
-* march <5>: HPPA Options. (line 9)
-* march <6>: CRIS Options. (line 10)
-* march: ARM Options. (line 112)
-* masm=DIALECT: i386 and x86-64 Options.
- (line 205)
-* mauto-incdec: M68hc1x Options. (line 26)
-* mauto-pic: IA-64 Options. (line 50)
-* mavoid-indexed-addresses: RS/6000 and PowerPC Options.
- (line 399)
-* mb: SH Options. (line 58)
-* mbackchain: S/390 and zSeries Options.
- (line 35)
-* mbase-addresses: MMIX Options. (line 54)
-* mbcopy: PDP-11 Options. (line 36)
-* mbig: RS/6000 and PowerPC Options.
- (line 474)
-* mbig-endian <1>: RS/6000 and PowerPC Options.
- (line 474)
-* mbig-endian <2>: MCore Options. (line 39)
-* mbig-endian <3>: IA-64 Options. (line 9)
-* mbig-endian: ARM Options. (line 72)
-* mbig-switch <1>: V850 Options. (line 52)
-* mbig-switch: HPPA Options. (line 23)
-* mbigtable: SH Options. (line 74)
-* mbit-align: RS/6000 and PowerPC Options.
- (line 428)
-* mbitfield: M680x0 Options. (line 231)
-* mbitops: SH Options. (line 78)
-* mbranch-cheap: PDP-11 Options. (line 65)
-* mbranch-cost: MIPS Options. (line 610)
-* mbranch-cost=NUMBER: M32R/D Options. (line 82)
-* mbranch-expensive: PDP-11 Options. (line 61)
-* mbranch-hints: SPU Options. (line 27)
-* mbranch-likely: MIPS Options. (line 617)
-* mbranch-predict: MMIX Options. (line 49)
-* mbss-plt: RS/6000 and PowerPC Options.
- (line 206)
-* mbuild-constants: DEC Alpha Options. (line 142)
-* mbwx: DEC Alpha Options. (line 171)
-* mc68000: M680x0 Options. (line 91)
-* mc68020: M680x0 Options. (line 105)
-* mcall-gnu: RS/6000 and PowerPC Options.
- (line 534)
-* mcall-linux: RS/6000 and PowerPC Options.
- (line 530)
-* mcall-netbsd: RS/6000 and PowerPC Options.
- (line 538)
-* mcall-prologues: AVR Options. (line 39)
-* mcall-solaris: RS/6000 and PowerPC Options.
- (line 526)
-* mcall-sysv: RS/6000 and PowerPC Options.
- (line 513)
-* mcall-sysv-eabi: RS/6000 and PowerPC Options.
- (line 520)
-* mcall-sysv-noeabi: RS/6000 and PowerPC Options.
- (line 523)
-* mcallee-super-interworking: ARM Options. (line 238)
-* mcaller-super-interworking: ARM Options. (line 244)
-* mcallgraph-data: MCore Options. (line 31)
-* mcc-init: CRIS Options. (line 41)
-* mcfv4e: M680x0 Options. (line 168)
-* mcheck-zero-division: MIPS Options. (line 425)
-* mcirrus-fix-invalid-insns: ARM Options. (line 189)
-* mcix: DEC Alpha Options. (line 171)
-* mcld: i386 and x86-64 Options.
- (line 458)
-* mcmodel=embmedany: SPARC Options. (line 213)
-* mcmodel=kernel: i386 and x86-64 Options.
- (line 629)
-* mcmodel=large: i386 and x86-64 Options.
- (line 641)
-* mcmodel=medany: SPARC Options. (line 207)
-* mcmodel=medium: i386 and x86-64 Options.
- (line 634)
-* mcmodel=medlow: SPARC Options. (line 196)
-* mcmodel=medmid: SPARC Options. (line 201)
-* mcmodel=small: i386 and x86-64 Options.
- (line 623)
-* mcmpb: RS/6000 and PowerPC Options.
- (line 31)
-* mcode-readable: MIPS Options. (line 385)
-* mcond-exec: FRV Options. (line 152)
-* mcond-move: FRV Options. (line 128)
-* 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)
-* mcorea: Blackfin Options. (line 149)
-* mcoreb: Blackfin Options. (line 155)
-* mcpu <1>: SPARC Options. (line 96)
-* mcpu <2>: RS/6000 and PowerPC Options.
- (line 114)
-* mcpu <3>: picoChip Options. (line 9)
-* mcpu <4>: M680x0 Options. (line 28)
-* mcpu <5>: i386 and x86-64 Options.
- (line 153)
-* mcpu <6>: FRV Options. (line 212)
-* mcpu <7>: DEC Alpha Options. (line 223)
-* mcpu <8>: CRIS Options. (line 10)
-* mcpu <9>: ARM Options. (line 84)
-* mcpu: ARC Options. (line 23)
-* mcpu32: M680x0 Options. (line 134)
-* mcpu= <1>: M32C Options. (line 7)
-* mcpu=: Blackfin Options. (line 7)
-* mcsync-anomaly: Blackfin Options. (line 55)
-* mcx16: i386 and x86-64 Options.
- (line 472)
-* mcygwin: i386 and x86-64 Windows Options.
- (line 16)
-* MD: Preprocessor Options.
- (line 262)
-* mdalign: SH Options. (line 64)
-* mdata: ARC Options. (line 30)
-* mdata-align: CRIS Options. (line 55)
-* mdebug <1>: S/390 and zSeries Options.
- (line 112)
-* mdebug: M32R/D Options. (line 69)
-* mdec-asm: PDP-11 Options. (line 78)
-* mdisable-callt: V850 Options. (line 80)
-* mdisable-fpregs: HPPA Options. (line 33)
-* mdisable-indexing: HPPA Options. (line 40)
-* mdiv <1>: MCore Options. (line 15)
-* mdiv: M680x0 Options. (line 205)
-* mdiv=STRATEGY: SH Options. (line 141)
-* mdivide-breaks: MIPS Options. (line 431)
-* mdivide-traps: MIPS Options. (line 431)
-* mdivsi3_libfunc=NAME: SH Options. (line 182)
-* mdll: i386 and x86-64 Windows Options.
- (line 30)
-* mdlmzb: RS/6000 and PowerPC Options.
- (line 421)
-* mdmx: MIPS Options. (line 278)
-* mdouble: FRV Options. (line 38)
-* mdouble-float <1>: RS/6000 and PowerPC Options.
- (line 347)
-* mdouble-float: MIPS Options. (line 236)
-* mdsp: MIPS Options. (line 255)
-* mdspr2: MIPS Options. (line 261)
-* mdual-nops: SPU Options. (line 55)
-* mdwarf2-asm: IA-64 Options. (line 79)
-* mdword: FRV Options. (line 32)
-* mdynamic-no-pic: RS/6000 and PowerPC Options.
- (line 479)
-* meabi: RS/6000 and PowerPC Options.
- (line 611)
-* mearly-stop-bits: IA-64 Options. (line 85)
-* meb: Score Options. (line 9)
-* mel: Score Options. (line 12)
-* melf <1>: MMIX Options. (line 44)
-* melf: CRIS Options. (line 87)
-* memb: RS/6000 and PowerPC Options.
- (line 606)
-* membedded-data: MIPS Options. (line 372)
-* memregs=: M32C Options. (line 21)
-* mep: V850 Options. (line 16)
-* mepsilon: MMIX Options. (line 15)
-* merror-reloc: SPU Options. (line 10)
-* mesa: S/390 and zSeries Options.
- (line 95)
-* metrax100: CRIS Options. (line 26)
-* metrax4: CRIS Options. (line 26)
-* mexplicit-relocs <1>: MIPS Options. (line 416)
-* mexplicit-relocs: DEC Alpha Options. (line 184)
-* mextern-sdata: MIPS Options. (line 334)
-* MF: Preprocessor Options.
- (line 208)
-* mfast-fp: Blackfin Options. (line 128)
-* mfast-indirect-calls: HPPA Options. (line 52)
-* mfaster-structs: SPARC Options. (line 71)
-* mfdpic: FRV Options. (line 56)
-* mfix: DEC Alpha Options. (line 171)
-* mfix-and-continue: Darwin Options. (line 106)
-* mfix-cortex-m3-ldrd: ARC Options. (line 36)
-* mfix-r10000: MIPS Options. (line 502)
-* mfix-r4000: MIPS Options. (line 481)
-* mfix-r4400: MIPS Options. (line 495)
-* mfix-sb1: MIPS Options. (line 534)
-* mfix-vr4120: MIPS Options. (line 513)
-* mfix-vr4130: MIPS Options. (line 527)
-* mfixed-cc: FRV Options. (line 28)
-* mfixed-range <1>: SPU Options. (line 47)
-* mfixed-range <2>: SH Options. (line 189)
-* mfixed-range <3>: IA-64 Options. (line 90)
-* mfixed-range: HPPA Options. (line 59)
-* mflip-mips16: MIPS Options. (line 109)
-* mfloat-abi: ARM Options. (line 41)
-* mfloat-gprs: RS/6000 and PowerPC Options.
- (line 235)
-* mfloat-ieee: DEC Alpha Options. (line 179)
-* mfloat-vax: DEC Alpha Options. (line 179)
-* mfloat32: PDP-11 Options. (line 52)
-* mfloat64: PDP-11 Options. (line 48)
-* mflush-func: MIPS Options. (line 601)
-* mflush-func=NAME: M32R/D Options. (line 94)
-* mflush-trap=NUMBER: M32R/D Options. (line 87)
-* mfmovd: SH Options. (line 81)
-* mfp: ARM Options. (line 124)
-* mfp-exceptions: MIPS Options. (line 628)
-* mfp-reg: DEC Alpha Options. (line 25)
-* mfp-rounding-mode: DEC Alpha Options. (line 85)
-* mfp-trap-mode: DEC Alpha Options. (line 63)
-* mfp32: MIPS Options. (line 219)
-* mfp64: MIPS Options. (line 222)
-* mfpe: ARM Options. (line 124)
-* mfpr-32: FRV Options. (line 13)
-* mfpr-64: FRV Options. (line 16)
-* mfprnd: RS/6000 and PowerPC Options.
- (line 31)
-* mfpu <1>: SPARC Options. (line 20)
-* mfpu <2>: RS/6000 and PowerPC Options.
- (line 355)
-* mfpu <3>: PDP-11 Options. (line 9)
-* mfpu: ARM Options. (line 124)
-* mfull-toc: RS/6000 and PowerPC Options.
- (line 263)
-* mfused-madd <1>: Xtensa Options. (line 19)
-* mfused-madd <2>: S/390 and zSeries Options.
- (line 137)
-* mfused-madd <3>: RS/6000 and PowerPC Options.
- (line 408)
-* mfused-madd <4>: MIPS Options. (line 466)
-* mfused-madd: i386 and x86-64 Options.
- (line 591)
-* mg: VAX Options. (line 17)
-* MG: Preprocessor Options.
- (line 217)
-* mgas <1>: HPPA Options. (line 75)
-* mgas: DEC Alpha Options. (line 159)
-* mgen-cell-microcode: RS/6000 and PowerPC Options.
- (line 194)
-* mgettrcost=NUMBER: SH Options. (line 211)
-* mglibc: GNU/Linux Options. (line 9)
-* mgnu: VAX Options. (line 13)
-* mgnu-as: IA-64 Options. (line 18)
-* mgnu-ld: IA-64 Options. (line 23)
-* mgotplt: CRIS Options. (line 81)
-* mgp32: MIPS Options. (line 213)
-* mgp64: MIPS Options. (line 216)
-* mgpopt: MIPS Options. (line 357)
-* mgpr-32: FRV Options. (line 7)
-* mgpr-64: FRV Options. (line 10)
-* mgprel-ro: FRV Options. (line 79)
-* mh: H8/300 Options. (line 14)
-* mhard-dfp <1>: S/390 and zSeries Options.
- (line 20)
-* mhard-dfp: RS/6000 and PowerPC Options.
- (line 31)
-* mhard-float <1>: SPARC Options. (line 20)
-* mhard-float <2>: S/390 and zSeries Options.
- (line 11)
-* mhard-float <3>: RS/6000 and PowerPC Options.
- (line 341)
-* mhard-float <4>: MIPS Options. (line 225)
-* mhard-float <5>: M680x0 Options. (line 193)
-* mhard-float <6>: FRV Options. (line 19)
-* mhard-float: ARM Options. (line 62)
-* mhard-quad-float: SPARC Options. (line 41)
-* mhardlit: MCore Options. (line 10)
-* mhint-max-distance: SPU Options. (line 67)
-* mhint-max-nops: SPU Options. (line 61)
-* mhitachi: SH Options. (line 84)
-* micplb: Blackfin Options. (line 168)
-* mid-shared-library: Blackfin Options. (line 76)
-* mieee <1>: SH Options. (line 99)
-* mieee: DEC Alpha Options. (line 39)
-* mieee-conformant: DEC Alpha Options. (line 134)
-* mieee-fp: i386 and x86-64 Options.
- (line 211)
-* mieee-with-inexact: DEC Alpha Options. (line 52)
-* milp32: IA-64 Options. (line 114)
-* mimpure-text: SPARC Options. (line 81)
-* mincoming-stack-boundary: i386 and x86-64 Options.
- (line 379)
-* mindexed-addressing: SH Options. (line 201)
-* minline-all-stringops: i386 and x86-64 Options.
- (line 553)
-* 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 106)
-* minline-int-divide-max-throughput: IA-64 Options. (line 66)
-* minline-int-divide-min-latency: IA-64 Options. (line 62)
-* minline-plt <1>: FRV Options. (line 64)
-* minline-plt: Blackfin Options. (line 133)
-* minline-sqrt-max-throughput: IA-64 Options. (line 74)
-* minline-sqrt-min-latency: IA-64 Options. (line 70)
-* minline-stringops-dynamically: i386 and x86-64 Options.
- (line 560)
-* minmax: M68hc1x Options. (line 31)
-* minsert-sched-nops: RS/6000 and PowerPC Options.
- (line 501)
-* mint16: PDP-11 Options. (line 40)
-* mint32 <1>: PDP-11 Options. (line 44)
-* mint32: H8/300 Options. (line 28)
-* mint8: AVR Options. (line 51)
-* minterlink-mips16: MIPS Options. (line 116)
-* minvalid-symbols: SH Options. (line 234)
-* mips1: MIPS Options. (line 76)
-* mips16: MIPS Options. (line 101)
-* mips2: MIPS Options. (line 79)
-* mips3: MIPS Options. (line 82)
-* mips32: MIPS Options. (line 88)
-* mips32r2: MIPS Options. (line 91)
-* mips3d: MIPS Options. (line 284)
-* mips4: MIPS Options. (line 85)
-* mips64: MIPS Options. (line 94)
-* mips64r2: MIPS Options. (line 97)
-* misel: RS/6000 and PowerPC Options.
- (line 212)
-* misize: SH Options. (line 118)
-* missue-rate=NUMBER: M32R/D Options. (line 79)
-* mjump-in-delay: HPPA Options. (line 28)
-* mkernel: Darwin Options. (line 84)
-* mknuthdiv: MMIX Options. (line 33)
-* ml: SH Options. (line 61)
-* mlarge-data: DEC Alpha Options. (line 195)
-* mlarge-data-threshold=NUMBER: i386 and x86-64 Options.
- (line 291)
-* mlarge-mem: SPU Options. (line 35)
-* mlarge-text: DEC Alpha Options. (line 213)
-* mleaf-id-shared-library: Blackfin Options. (line 87)
-* mlibfuncs: MMIX Options. (line 10)
-* mlibrary-pic: FRV Options. (line 110)
-* mlinked-fp: FRV Options. (line 94)
-* mlinker-opt: HPPA Options. (line 85)
-* mlinux: CRIS Options. (line 91)
-* mlittle: RS/6000 and PowerPC Options.
- (line 468)
-* mlittle-endian <1>: SPARC Options. (line 185)
-* mlittle-endian <2>: RS/6000 and PowerPC Options.
- (line 468)
-* mlittle-endian <3>: MCore Options. (line 39)
-* mlittle-endian <4>: IA-64 Options. (line 13)
-* mlittle-endian: ARM Options. (line 68)
-* mllsc: MIPS Options. (line 241)
-* mlocal-sdata: MIPS Options. (line 322)
-* mlong-calls <1>: V850 Options. (line 10)
-* mlong-calls <2>: MIPS Options. (line 452)
-* mlong-calls <3>: M68hc1x Options. (line 35)
-* mlong-calls <4>: FRV Options. (line 99)
-* mlong-calls <5>: Blackfin Options. (line 116)
-* mlong-calls: ARM Options. (line 154)
-* mlong-double-128: S/390 and zSeries Options.
- (line 29)
-* mlong-double-64: S/390 and zSeries Options.
- (line 29)
-* mlong-load-store: HPPA Options. (line 66)
-* mlong32: MIPS Options. (line 297)
-* mlong64: MIPS Options. (line 292)
-* mlongcall: RS/6000 and PowerPC Options.
- (line 677)
-* mlongcalls: Xtensa Options. (line 67)
-* mlow-64k: Blackfin Options. (line 65)
-* mlp64: IA-64 Options. (line 114)
-* MM: Preprocessor Options.
- (line 198)
-* mmac <1>: Score Options. (line 21)
-* mmac: CRX Options. (line 9)
-* mmad: MIPS Options. (line 461)
-* mmangle-cpu: ARC Options. (line 15)
-* mmax: DEC Alpha Options. (line 171)
-* mmax-stack-frame: CRIS Options. (line 22)
-* mmcu: AVR Options. (line 9)
-* MMD: Preprocessor Options.
- (line 278)
-* mmedia: FRV Options. (line 44)
-* mmemcpy: MIPS Options. (line 446)
-* mmemory-latency: DEC Alpha Options. (line 276)
-* mmfcrf: RS/6000 and PowerPC Options.
- (line 31)
-* mmfpgpr: RS/6000 and PowerPC Options.
- (line 31)
-* mminimal-toc: RS/6000 and PowerPC Options.
- (line 263)
-* mmmx: i386 and x86-64 Options.
- (line 435)
-* mmodel=large: M32R/D Options. (line 33)
-* mmodel=medium: M32R/D Options. (line 27)
-* mmodel=small: M32R/D Options. (line 18)
-* mmt: MIPS Options. (line 289)
-* mmul-bug-workaround: CRIS Options. (line 31)
-* mmuladd: FRV Options. (line 50)
-* mmulhw: RS/6000 and PowerPC Options.
- (line 414)
-* mmult-bug: MN10300 Options. (line 9)
-* mmulti-cond-exec: FRV Options. (line 176)
-* mmulticore: Blackfin Options. (line 137)
-* mmultiple: RS/6000 and PowerPC Options.
- (line 366)
-* mmvcle: S/390 and zSeries Options.
- (line 105)
-* mmvme: RS/6000 and PowerPC Options.
- (line 587)
-* mn: H8/300 Options. (line 20)
-* mnested-cond-exec: FRV Options. (line 189)
-* mnew-mnemonics: RS/6000 and PowerPC Options.
- (line 99)
-* mnhwloop: Score Options. (line 15)
-* mno-3dnow: i386 and x86-64 Options.
- (line 435)
-* mno-4byte-functions: MCore Options. (line 27)
-* mno-abicalls: MIPS Options. (line 153)
-* mno-abshi: PDP-11 Options. (line 58)
-* mno-ac0: PDP-11 Options. (line 20)
-* mno-align-double: i386 and x86-64 Options.
- (line 249)
-* mno-align-int: M680x0 Options. (line 263)
-* mno-align-loops: M32R/D Options. (line 76)
-* mno-align-stringops: i386 and x86-64 Options.
- (line 548)
-* mno-altivec: RS/6000 and PowerPC Options.
- (line 183)
-* mno-am33: MN10300 Options. (line 20)
-* mno-app-regs <1>: V850 Options. (line 61)
-* mno-app-regs: SPARC Options. (line 10)
-* mno-avoid-indexed-addresses: RS/6000 and PowerPC Options.
- (line 399)
-* mno-backchain: S/390 and zSeries Options.
- (line 35)
-* mno-base-addresses: MMIX Options. (line 54)
-* mno-bit-align: RS/6000 and PowerPC Options.
- (line 428)
-* mno-bitfield: M680x0 Options. (line 227)
-* mno-branch-likely: MIPS Options. (line 617)
-* mno-branch-predict: MMIX Options. (line 49)
-* mno-bwx: DEC Alpha Options. (line 171)
-* mno-callgraph-data: MCore Options. (line 31)
-* mno-check-zero-division: MIPS Options. (line 425)
-* mno-cirrus-fix-invalid-insns: ARM Options. (line 189)
-* mno-cix: DEC Alpha Options. (line 171)
-* mno-cmpb: RS/6000 and PowerPC Options.
- (line 31)
-* mno-cond-exec: FRV Options. (line 158)
-* mno-cond-move: FRV Options. (line 134)
-* mno-const-align: CRIS Options. (line 55)
-* mno-const16: Xtensa Options. (line 10)
-* mno-crt0: MN10300 Options. (line 31)
-* mno-csync-anomaly: Blackfin Options. (line 61)
-* mno-cygwin: i386 and x86-64 Windows Options.
- (line 23)
-* mno-data-align: CRIS Options. (line 55)
-* mno-debug: S/390 and zSeries Options.
- (line 112)
-* mno-div <1>: MCore Options. (line 15)
-* mno-div: M680x0 Options. (line 205)
-* mno-dlmzb: RS/6000 and PowerPC Options.
- (line 421)
-* mno-double: FRV Options. (line 41)
-* mno-dsp: MIPS Options. (line 255)
-* mno-dspr2: MIPS Options. (line 261)
-* mno-dwarf2-asm: IA-64 Options. (line 79)
-* mno-dword: FRV Options. (line 35)
-* mno-eabi: RS/6000 and PowerPC Options.
- (line 611)
-* mno-early-stop-bits: IA-64 Options. (line 85)
-* mno-eflags: FRV Options. (line 125)
-* mno-embedded-data: MIPS Options. (line 372)
-* mno-ep: V850 Options. (line 16)
-* mno-epsilon: MMIX Options. (line 15)
-* mno-explicit-relocs <1>: MIPS Options. (line 416)
-* mno-explicit-relocs: DEC Alpha Options. (line 184)
-* mno-extern-sdata: MIPS Options. (line 334)
-* mno-fancy-math-387: i386 and x86-64 Options.
- (line 238)
-* mno-faster-structs: SPARC Options. (line 71)
-* mno-fix: DEC Alpha Options. (line 171)
-* mno-fix-r10000: MIPS Options. (line 502)
-* mno-fix-r4000: MIPS Options. (line 481)
-* mno-fix-r4400: MIPS Options. (line 495)
-* mno-float32: PDP-11 Options. (line 48)
-* mno-float64: PDP-11 Options. (line 52)
-* mno-flush-func: M32R/D Options. (line 99)
-* mno-flush-trap: M32R/D Options. (line 91)
-* mno-fp-in-toc: RS/6000 and PowerPC Options.
- (line 263)
-* mno-fp-regs: DEC Alpha Options. (line 25)
-* mno-fp-ret-in-387: i386 and x86-64 Options.
- (line 228)
-* mno-fprnd: RS/6000 and PowerPC Options.
- (line 31)
-* mno-fpu: SPARC Options. (line 25)
-* mno-fused-madd <1>: Xtensa Options. (line 19)
-* mno-fused-madd <2>: S/390 and zSeries Options.
- (line 137)
-* mno-fused-madd <3>: RS/6000 and PowerPC Options.
- (line 408)
-* mno-fused-madd: MIPS Options. (line 466)
-* mno-gnu-as: IA-64 Options. (line 18)
-* mno-gnu-ld: IA-64 Options. (line 23)
-* mno-gotplt: CRIS Options. (line 81)
-* mno-gpopt: MIPS Options. (line 357)
-* mno-hard-dfp <1>: S/390 and zSeries Options.
- (line 20)
-* mno-hard-dfp: RS/6000 and PowerPC Options.
- (line 31)
-* mno-hardlit: MCore Options. (line 10)
-* mno-id-shared-library: Blackfin Options. (line 83)
-* mno-ieee-fp: i386 and x86-64 Options.
- (line 211)
-* mno-int16: PDP-11 Options. (line 44)
-* mno-int32: PDP-11 Options. (line 40)
-* mno-interlink-mips16: MIPS Options. (line 116)
-* mno-interrupts: AVR Options. (line 35)
-* mno-isel: RS/6000 and PowerPC Options.
- (line 212)
-* mno-knuthdiv: MMIX Options. (line 33)
-* mno-leaf-id-shared-library: Blackfin Options. (line 93)
-* mno-libfuncs: MMIX Options. (line 10)
-* mno-llsc: MIPS Options. (line 241)
-* mno-local-sdata: MIPS Options. (line 322)
-* mno-long-calls <1>: V850 Options. (line 10)
-* mno-long-calls <2>: MIPS Options. (line 452)
-* mno-long-calls <3>: M68hc1x Options. (line 35)
-* mno-long-calls <4>: HPPA Options. (line 136)
-* mno-long-calls <5>: Blackfin Options. (line 116)
-* mno-long-calls: ARM Options. (line 154)
-* mno-longcall: RS/6000 and PowerPC Options.
- (line 677)
-* mno-longcalls: Xtensa Options. (line 67)
-* mno-low-64k: Blackfin Options. (line 69)
-* mno-lsim: FR30 Options. (line 14)
-* mno-mad: MIPS Options. (line 461)
-* mno-max: DEC Alpha Options. (line 171)
-* mno-mdmx: MIPS Options. (line 278)
-* mno-media: FRV Options. (line 47)
-* mno-memcpy: MIPS Options. (line 446)
-* mno-mfcrf: RS/6000 and PowerPC Options.
- (line 31)
-* mno-mfpgpr: RS/6000 and PowerPC Options.
- (line 31)
-* mno-mips16: MIPS Options. (line 101)
-* mno-mips3d: MIPS Options. (line 284)
-* mno-mmx: i386 and x86-64 Options.
- (line 435)
-* mno-mt: MIPS Options. (line 289)
-* mno-mul-bug-workaround: CRIS Options. (line 31)
-* mno-muladd: FRV Options. (line 53)
-* mno-mulhw: RS/6000 and PowerPC Options.
- (line 414)
-* mno-mult-bug: MN10300 Options. (line 13)
-* mno-multi-cond-exec: FRV Options. (line 183)
-* mno-multiple: RS/6000 and PowerPC Options.
- (line 366)
-* mno-mvcle: S/390 and zSeries Options.
- (line 105)
-* mno-nested-cond-exec: FRV Options. (line 195)
-* mno-optimize-membar: FRV Options. (line 205)
-* mno-pack: FRV Options. (line 122)
-* mno-packed-stack: S/390 and zSeries Options.
- (line 54)
-* mno-paired: RS/6000 and PowerPC Options.
- (line 226)
-* mno-paired-single: MIPS Options. (line 272)
-* mno-pic: IA-64 Options. (line 26)
-* mno-plt: MIPS Options. (line 180)
-* mno-popcntb: RS/6000 and PowerPC Options.
- (line 31)
-* mno-power: RS/6000 and PowerPC Options.
- (line 31)
-* mno-power2: RS/6000 and PowerPC Options.
- (line 31)
-* mno-powerpc: RS/6000 and PowerPC Options.
- (line 31)
-* mno-powerpc-gfxopt: RS/6000 and PowerPC Options.
- (line 31)
-* mno-powerpc-gpopt: RS/6000 and PowerPC Options.
- (line 31)
-* mno-powerpc64: RS/6000 and PowerPC Options.
- (line 31)
-* mno-prolog-function: V850 Options. (line 23)
-* mno-prologue-epilogue: CRIS Options. (line 71)
-* mno-prototype: RS/6000 and PowerPC Options.
- (line 571)
-* mno-push-args: i386 and x86-64 Options.
- (line 525)
-* mno-register-names: IA-64 Options. (line 37)
-* mno-regnames: RS/6000 and PowerPC Options.
- (line 671)
-* mno-relax-immediate: MCore Options. (line 19)
-* mno-relocatable: RS/6000 and PowerPC Options.
- (line 445)
-* mno-relocatable-lib: RS/6000 and PowerPC Options.
- (line 453)
-* mno-rtd: M680x0 Options. (line 258)
-* mno-scc: FRV Options. (line 146)
-* mno-sched-ar-data-spec: IA-64 Options. (line 128)
-* mno-sched-ar-in-data-spec: IA-64 Options. (line 149)
-* mno-sched-br-data-spec: IA-64 Options. (line 121)
-* mno-sched-br-in-data-spec: IA-64 Options. (line 142)
-* mno-sched-control-ldc: IA-64 Options. (line 168)
-* mno-sched-control-spec: IA-64 Options. (line 135)
-* mno-sched-count-spec-in-critical-path: IA-64 Options. (line 194)
-* mno-sched-in-control-spec: IA-64 Options. (line 156)
-* mno-sched-ldc: IA-64 Options. (line 162)
-* mno-sched-prefer-non-control-spec-insns: IA-64 Options. (line 187)
-* mno-sched-prefer-non-data-spec-insns: IA-64 Options. (line 180)
-* mno-sched-prolog: ARM Options. (line 32)
-* mno-sched-spec-verbose: IA-64 Options. (line 176)
-* mno-sdata <1>: RS/6000 and PowerPC Options.
- (line 658)
-* mno-sdata: IA-64 Options. (line 42)
-* mno-sep-data: Blackfin Options. (line 111)
-* mno-serialize-volatile: Xtensa Options. (line 35)
-* mno-short: M680x0 Options. (line 222)
-* mno-side-effects: CRIS Options. (line 46)
-* mno-single-exit: MMIX Options. (line 66)
-* mno-slow-bytes: MCore Options. (line 35)
-* mno-small-exec: S/390 and zSeries Options.
- (line 80)
-* mno-smartmips: MIPS Options. (line 268)
-* mno-soft-float: DEC Alpha Options. (line 10)
-* mno-space-regs: HPPA Options. (line 45)
-* mno-spe: RS/6000 and PowerPC Options.
- (line 221)
-* mno-specld-anomaly: Blackfin Options. (line 51)
-* mno-split: PDP-11 Options. (line 71)
-* mno-split-addresses: MIPS Options. (line 410)
-* mno-sse: i386 and x86-64 Options.
- (line 435)
-* mno-stack-align: CRIS Options. (line 55)
-* mno-stack-bias: SPARC Options. (line 222)
-* mno-strict-align <1>: RS/6000 and PowerPC Options.
- (line 440)
-* mno-strict-align: M680x0 Options. (line 283)
-* mno-string: RS/6000 and PowerPC Options.
- (line 377)
-* mno-sum-in-toc: RS/6000 and PowerPC Options.
- (line 263)
-* mno-swdiv: RS/6000 and PowerPC Options.
- (line 173)
-* mno-sym32: MIPS Options. (line 307)
-* mno-tablejump: AVR Options. (line 43)
-* mno-target-align: Xtensa Options. (line 54)
-* mno-text-section-literals: Xtensa Options. (line 42)
-* mno-toc: RS/6000 and PowerPC Options.
- (line 462)
-* mno-toplevel-symbols: MMIX Options. (line 40)
-* mno-tpf-trace: S/390 and zSeries Options.
- (line 131)
-* mno-unaligned-doubles: SPARC Options. (line 59)
-* mno-uninit-const-in-rodata: MIPS Options. (line 380)
-* mno-update: RS/6000 and PowerPC Options.
- (line 388)
-* mno-v8plus: SPARC Options. (line 170)
-* mno-vis: SPARC Options. (line 177)
-* mno-vliw-branch: FRV Options. (line 170)
-* mno-volatile-asm-stop: IA-64 Options. (line 32)
-* mno-vrsave: RS/6000 and PowerPC Options.
- (line 191)
-* mno-wide-bitfields: MCore Options. (line 23)
-* mno-xgot <1>: MIPS Options. (line 190)
-* mno-xgot: M680x0 Options. (line 315)
-* mno-xl-compat: RS/6000 and PowerPC Options.
- (line 298)
-* mno-zero-extend: MMIX Options. (line 27)
-* mnobitfield: M680x0 Options. (line 227)
-* mnomacsave: SH Options. (line 95)
-* mnominmax: M68hc1x Options. (line 31)
-* mnop-fun-dllimport: i386 and x86-64 Windows Options.
- (line 36)
-* mold-mnemonics: RS/6000 and PowerPC Options.
- (line 99)
-* momit-leaf-frame-pointer <1>: i386 and x86-64 Options.
- (line 573)
-* momit-leaf-frame-pointer: Blackfin Options. (line 39)
-* mone-byte-bool: Darwin Options. (line 92)
-* moptimize-membar: FRV Options. (line 201)
-* MP: Preprocessor Options.
- (line 227)
-* 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 119)
-* mpacked-stack: S/390 and zSeries Options.
- (line 54)
-* mpadstruct: SH Options. (line 121)
-* mpaired: RS/6000 and PowerPC Options.
- (line 226)
-* mpaired-single: MIPS Options. (line 272)
-* mpc32: i386 and x86-64 Options.
- (line 344)
-* mpc64: i386 and x86-64 Options.
- (line 344)
-* mpc80: i386 and x86-64 Options.
- (line 344)
-* mpcrel: M680x0 Options. (line 275)
-* mpdebug: CRIS Options. (line 35)
-* mpe: RS/6000 and PowerPC Options.
- (line 318)
-* mpic-register: ARM Options. (line 185)
-* mplt: MIPS Options. (line 180)
-* mpoke-function-name: ARM Options. (line 199)
-* mpopcntb: RS/6000 and PowerPC Options.
- (line 31)
-* mportable-runtime: HPPA Options. (line 71)
-* mpower: RS/6000 and PowerPC Options.
- (line 31)
-* mpower2: RS/6000 and PowerPC Options.
- (line 31)
-* mpowerpc: RS/6000 and PowerPC Options.
- (line 31)
-* mpowerpc-gfxopt: RS/6000 and PowerPC Options.
- (line 31)
-* mpowerpc-gpopt: RS/6000 and PowerPC Options.
- (line 31)
-* mpowerpc64: RS/6000 and PowerPC Options.
- (line 31)
-* mprefergot: SH Options. (line 128)
-* mpreferred-stack-boundary: i386 and x86-64 Options.
- (line 374)
-* mprioritize-restricted-insns: RS/6000 and PowerPC Options.
- (line 485)
-* mprolog-function: V850 Options. (line 23)
-* mprologue-epilogue: CRIS Options. (line 71)
-* mprototype: RS/6000 and PowerPC Options.
- (line 571)
-* mpt-fixed: SH Options. (line 215)
-* mpush-args <1>: i386 and x86-64 Options.
- (line 525)
-* mpush-args: CRX Options. (line 13)
-* MQ: Preprocessor Options.
- (line 253)
-* mr10k-cache-barrier: MIPS Options. (line 539)
-* mrecip: i386 and x86-64 Options.
- (line 490)
-* mregister-names: IA-64 Options. (line 37)
-* mregnames: RS/6000 and PowerPC Options.
- (line 671)
-* mregparm: i386 and x86-64 Options.
- (line 321)
-* mrelax <1>: SH Options. (line 70)
-* mrelax <2>: MN10300 Options. (line 34)
-* mrelax: H8/300 Options. (line 9)
-* mrelax-immediate: MCore Options. (line 19)
-* mrelocatable: RS/6000 and PowerPC Options.
- (line 445)
-* mrelocatable-lib: RS/6000 and PowerPC Options.
- (line 453)
-* mreturn-pointer-on-d0: MN10300 Options. (line 24)
-* mrodata: ARC Options. (line 30)
-* mrtd <1>: Function Attributes.
- (line 170)
-* mrtd <2>: M680x0 Options. (line 236)
-* mrtd: i386 and x86-64 Options.
- (line 297)
-* mrtp: VxWorks Options. (line 11)
-* ms: H8/300 Options. (line 17)
-* ms2600: H8/300 Options. (line 24)
-* msafe-dma: SPU Options. (line 17)
-* msafe-hints: SPU Options. (line 72)
-* msahf: i386 and x86-64 Options.
- (line 480)
-* mscc: FRV Options. (line 140)
-* msched-ar-data-spec: IA-64 Options. (line 128)
-* msched-ar-in-data-spec: IA-64 Options. (line 149)
-* msched-br-data-spec: IA-64 Options. (line 121)
-* msched-br-in-data-spec: IA-64 Options. (line 142)
-* msched-control-ldc: IA-64 Options. (line 168)
-* msched-control-spec: IA-64 Options. (line 135)
-* msched-costly-dep: RS/6000 and PowerPC Options.
- (line 492)
-* msched-count-spec-in-critical-path: IA-64 Options. (line 194)
-* msched-in-control-spec: IA-64 Options. (line 156)
-* msched-ldc: IA-64 Options. (line 162)
-* msched-prefer-non-control-spec-insns: IA-64 Options. (line 187)
-* msched-prefer-non-data-spec-insns: IA-64 Options. (line 180)
-* msched-spec-verbose: IA-64 Options. (line 176)
-* mschedule: HPPA Options. (line 78)
-* mscore5: Score Options. (line 25)
-* mscore5u: Score Options. (line 28)
-* mscore7: Score Options. (line 31)
-* mscore7d: Score Options. (line 34)
-* msda: V850 Options. (line 40)
-* msdata <1>: RS/6000 and PowerPC Options.
- (line 645)
-* msdata: IA-64 Options. (line 42)
-* msdata=data: RS/6000 and PowerPC Options.
- (line 650)
-* msdata=default: RS/6000 and PowerPC Options.
- (line 645)
-* msdata=eabi: RS/6000 and PowerPC Options.
- (line 625)
-* msdata=none <1>: RS/6000 and PowerPC Options.
- (line 658)
-* msdata=none: M32R/D Options. (line 40)
-* msdata=sdata: M32R/D Options. (line 49)
-* msdata=sysv: RS/6000 and PowerPC Options.
- (line 636)
-* msdata=use: M32R/D Options. (line 53)
-* msdram: Blackfin Options. (line 162)
-* msecure-plt: RS/6000 and PowerPC Options.
- (line 201)
-* msep-data: Blackfin Options. (line 105)
-* mserialize-volatile: Xtensa Options. (line 35)
-* mshared-library-id: Blackfin Options. (line 98)
-* mshort <1>: M68hc1x Options. (line 40)
-* mshort: M680x0 Options. (line 216)
-* msim <1>: Xstormy16 Options. (line 9)
-* msim <2>: RS/6000 and PowerPC Options.
- (line 581)
-* msim <3>: M32C Options. (line 13)
-* msim: Blackfin Options. (line 32)
-* msimple-fpu: RS/6000 and PowerPC Options.
- (line 351)
-* msingle-exit: MMIX Options. (line 66)
-* msingle-float <1>: RS/6000 and PowerPC Options.
- (line 347)
-* msingle-float: MIPS Options. (line 232)
-* msingle-pic-base: ARM Options. (line 179)
-* msio: HPPA Options. (line 105)
-* msize: AVR Options. (line 32)
-* mslow-bytes: MCore Options. (line 35)
-* msmall-data: DEC Alpha Options. (line 195)
-* msmall-exec: S/390 and zSeries Options.
- (line 80)
-* msmall-mem: SPU Options. (line 35)
-* msmall-model: FR30 Options. (line 9)
-* msmall-text: DEC Alpha Options. (line 213)
-* msmartmips: MIPS Options. (line 268)
-* msoft-float <1>: SPARC Options. (line 25)
-* msoft-float <2>: S/390 and zSeries Options.
- (line 11)
-* msoft-float <3>: RS/6000 and PowerPC Options.
- (line 341)
-* msoft-float <4>: PDP-11 Options. (line 13)
-* msoft-float <5>: MIPS Options. (line 228)
-* msoft-float <6>: M680x0 Options. (line 199)
-* msoft-float <7>: i386 and x86-64 Options.
- (line 216)
-* msoft-float <8>: HPPA Options. (line 91)
-* msoft-float <9>: FRV Options. (line 22)
-* msoft-float <10>: DEC Alpha Options. (line 10)
-* msoft-float: ARM Options. (line 65)
-* msoft-quad-float: SPARC Options. (line 45)
-* msoft-reg-count: M68hc1x Options. (line 43)
-* mspace <1>: V850 Options. (line 30)
-* mspace: SH Options. (line 125)
-* mspe: RS/6000 and PowerPC Options.
- (line 221)
-* mspecld-anomaly: Blackfin Options. (line 46)
-* msplit: PDP-11 Options. (line 68)
-* msplit-addresses: MIPS Options. (line 410)
-* msse: i386 and x86-64 Options.
- (line 435)
-* msse2avx: i386 and x86-64 Options.
- (line 599)
-* msseregparm: i386 and x86-64 Options.
- (line 332)
-* mstack-align: CRIS Options. (line 55)
-* mstack-bias: SPARC Options. (line 222)
-* mstack-check-l1: Blackfin Options. (line 72)
-* mstack-guard: S/390 and zSeries Options.
- (line 156)
-* mstack-increment: MCore Options. (line 50)
-* mstack-size: S/390 and zSeries Options.
- (line 156)
-* mstackrealign: i386 and x86-64 Options.
- (line 365)
-* mstdmain: SPU Options. (line 40)
-* mstrict-align <1>: RS/6000 and PowerPC Options.
- (line 440)
-* mstrict-align: M680x0 Options. (line 283)
-* mstring: RS/6000 and PowerPC Options.
- (line 377)
-* mstringop-strategy=ALG: i386 and x86-64 Options.
- (line 565)
-* mstructure-size-boundary: ARM Options. (line 134)
-* msvr4-struct-return: RS/6000 and PowerPC Options.
- (line 545)
-* mswdiv: RS/6000 and PowerPC Options.
- (line 173)
-* msym32: MIPS Options. (line 307)
-* mt: IA-64 Options. (line 106)
-* MT: Preprocessor Options.
- (line 239)
-* mtarget-align: Xtensa Options. (line 54)
-* mtda: V850 Options. (line 34)
-* mtext: ARC Options. (line 30)
-* mtext-section-literals: Xtensa Options. (line 42)
-* mthread: i386 and x86-64 Windows Options.
- (line 40)
-* mthreads: i386 and x86-64 Options.
- (line 540)
-* mthumb: ARM Options. (line 220)
-* mthumb-interwork: ARM Options. (line 25)
-* mtiny-stack: AVR Options. (line 48)
-* mtls-direct-seg-refs: i386 and x86-64 Options.
- (line 581)
-* mtls-size: IA-64 Options. (line 97)
-* mtoc: RS/6000 and PowerPC Options.
- (line 462)
-* mtomcat-stats: FRV Options. (line 209)
-* mtoplevel-symbols: MMIX Options. (line 40)
-* mtp: ARM Options. (line 250)
-* mtpcs-frame: ARM Options. (line 226)
-* mtpcs-leaf-frame: ARM Options. (line 232)
-* mtpf-trace: S/390 and zSeries Options.
- (line 131)
-* mtrap-precision: DEC Alpha Options. (line 109)
-* mtune <1>: SPARC Options. (line 158)
-* mtune <2>: S/390 and zSeries Options.
- (line 124)
-* mtune <3>: RS/6000 and PowerPC Options.
- (line 163)
-* mtune <4>: MIPS Options. (line 61)
-* mtune <5>: M680x0 Options. (line 66)
-* mtune <6>: IA-64 Options. (line 101)
-* mtune <7>: i386 and x86-64 Options.
- (line 10)
-* mtune <8>: DEC Alpha Options. (line 267)
-* mtune <9>: CRIS Options. (line 16)
-* mtune: ARM Options. (line 102)
-* muclibc: GNU/Linux Options. (line 13)
-* muls: Score Options. (line 18)
-* multcost=NUMBER: SH Options. (line 138)
-* multi_module: Darwin Options. (line 199)
-* multilib-library-pic: FRV Options. (line 89)
-* multiply_defined: Darwin Options. (line 199)
-* multiply_defined_unused: Darwin Options. (line 199)
-* munaligned-doubles: SPARC Options. (line 59)
-* muninit-const-in-rodata: MIPS Options. (line 380)
-* munix: VAX Options. (line 9)
-* munix-asm: PDP-11 Options. (line 74)
-* munsafe-dma: SPU Options. (line 17)
-* mupdate: RS/6000 and PowerPC Options.
- (line 388)
-* musermode: SH Options. (line 133)
-* mv850: V850 Options. (line 49)
-* mv850e: V850 Options. (line 69)
-* mv850e1: V850 Options. (line 64)
-* mv8plus: SPARC Options. (line 170)
-* mveclibabi: i386 and x86-64 Options.
- (line 503)
-* mvis: SPARC Options. (line 177)
-* mvliw-branch: FRV Options. (line 164)
-* mvms-return-codes: DEC Alpha/VMS Options.
- (line 9)
-* mvolatile-asm-stop: IA-64 Options. (line 32)
-* mvr4130-align: MIPS Options. (line 638)
-* mvrsave: RS/6000 and PowerPC Options.
- (line 191)
-* mvxworks: RS/6000 and PowerPC Options.
- (line 602)
-* mwarn-cell-microcode: RS/6000 and PowerPC Options.
- (line 197)
-* mwarn-dynamicstack: S/390 and zSeries Options.
- (line 150)
-* mwarn-framesize: S/390 and zSeries Options.
- (line 142)
-* mwarn-reloc: SPU Options. (line 10)
-* mwide-bitfields: MCore Options. (line 23)
-* mwin32: i386 and x86-64 Windows Options.
- (line 44)
-* mwindows: i386 and x86-64 Windows Options.
- (line 50)
-* mword-relocations: ARM Options. (line 258)
-* mwords-little-endian: ARM Options. (line 76)
-* mxgot <1>: MIPS Options. (line 190)
-* mxgot: M680x0 Options. (line 315)
-* mxilinx-fpu: RS/6000 and PowerPC Options.
- (line 361)
-* mxl-compat: RS/6000 and PowerPC Options.
- (line 298)
-* myellowknife: RS/6000 and PowerPC Options.
- (line 597)
-* mzarch: S/390 and zSeries Options.
- (line 95)
-* mzda: V850 Options. (line 45)
-* mzero-extend: MMIX Options. (line 27)
-* no-integrated-cpp: C Dialect Options. (line 240)
-* no-lsim: MCore Options. (line 46)
-* no-red-zone: i386 and x86-64 Options.
- (line 615)
-* no_dead_strip_inits_and_terms: Darwin Options. (line 199)
-* noall_load: Darwin Options. (line 199)
-* nocpp: MIPS Options. (line 476)
-* nodefaultlibs: Link Options. (line 62)
-* nofixprebinding: Darwin Options. (line 199)
-* nolibdld: HPPA Options. (line 188)
-* nomultidefs: Darwin Options. (line 199)
-* non-static: VxWorks Options. (line 16)
-* noprebind: Darwin Options. (line 199)
-* noseglinkedit: Darwin Options. (line 199)
-* nostartfiles: Link Options. (line 57)
-* nostdinc: Preprocessor Options.
- (line 375)
-* nostdinc++ <1>: Preprocessor Options.
- (line 380)
-* nostdinc++: C++ Dialect Options.
- (line 272)
-* nostdlib: Link Options. (line 71)
-* o: Preprocessor Options.
- (line 75)
-* O: Optimize Options. (line 29)
-* o: Overall Options. (line 187)
-* O0: Optimize Options. (line 106)
-* O1: Optimize Options. (line 29)
-* O2: Optimize Options. (line 67)
-* O3: Optimize Options. (line 100)
-* Os: Optimize Options. (line 110)
-* P: Preprocessor Options.
- (line 591)
-* p: Debugging Options. (line 219)
-* pagezero_size: Darwin Options. (line 199)
-* param: Optimize Options. (line 1702)
-* pass-exit-codes: Overall Options. (line 145)
-* pedantic <1>: Warnings and Errors.
- (line 25)
-* pedantic <2>: Alternate Keywords. (line 29)
-* pedantic <3>: C Extensions. (line 6)
-* pedantic <4>: Preprocessor Options.
- (line 163)
-* pedantic <5>: Warning Options. (line 53)
-* pedantic: Standards. (line 16)
-* pedantic-errors <1>: Warnings and Errors.
- (line 25)
-* pedantic-errors <2>: Non-bugs. (line 216)
-* pedantic-errors <3>: Preprocessor Options.
- (line 168)
-* pedantic-errors <4>: Warning Options. (line 95)
-* pedantic-errors: Standards. (line 16)
-* pg: Debugging Options. (line 225)
-* pie: Link Options. (line 92)
-* pipe: Overall Options. (line 209)
-* prebind: Darwin Options. (line 199)
-* prebind_all_twolevel_modules: Darwin Options. (line 199)
-* print-file-name: Debugging Options. (line 884)
-* print-libgcc-file-name: Debugging Options. (line 905)
-* print-multi-directory: Debugging Options. (line 890)
-* print-multi-lib: Debugging Options. (line 895)
-* print-objc-runtime-info: Objective-C and Objective-C++ Dialect Options.
- (line 244)
-* print-prog-name: Debugging Options. (line 902)
-* print-search-dirs: Debugging Options. (line 913)
-* print-sysroot: Debugging Options. (line 926)
-* print-sysroot-headers-suffix: Debugging Options. (line 933)
-* private_bundle: Darwin Options. (line 199)
-* pthread <1>: SPARC Options. (line 242)
-* pthread <2>: RS/6000 and PowerPC Options.
- (line 709)
-* pthread: IA-64 Options. (line 106)
-* pthreads: SPARC Options. (line 236)
-* Q: Debugging Options. (line 231)
-* Qn: System V Options. (line 18)
-* Qy: System V Options. (line 14)
-* rdynamic: Link Options. (line 98)
-* read_only_relocs: Darwin Options. (line 199)
-* remap: Preprocessor Options.
- (line 639)
-* s: Link Options. (line 105)
-* S <1>: Link Options. (line 20)
-* S: Overall Options. (line 170)
-* save-temps: Debugging Options. (line 846)
-* sectalign: Darwin Options. (line 199)
-* sectcreate: Darwin Options. (line 199)
-* sectobjectsymbols: Darwin Options. (line 199)
-* sectorder: Darwin Options. (line 199)
-* seg1addr: Darwin Options. (line 199)
-* seg_addr_table: Darwin Options. (line 199)
-* seg_addr_table_filename: Darwin Options. (line 199)
-* segaddr: Darwin Options. (line 199)
-* seglinkedit: Darwin Options. (line 199)
-* segprot: Darwin Options. (line 199)
-* segs_read_only_addr: Darwin Options. (line 199)
-* segs_read_write_addr: Darwin Options. (line 199)
-* shared: Link Options. (line 114)
-* shared-libgcc: Link Options. (line 122)
-* sim: CRIS Options. (line 95)
-* sim2: CRIS Options. (line 101)
-* single_module: Darwin Options. (line 199)
-* specs: Directory Options. (line 84)
-* static <1>: HPPA Options. (line 192)
-* static <2>: Darwin Options. (line 199)
-* static: Link Options. (line 109)
-* static-libgcc: Link Options. (line 122)
-* std <1>: Non-bugs. (line 107)
-* std <2>: Other Builtins. (line 22)
-* std <3>: C Dialect Options. (line 47)
-* std: Standards. (line 16)
-* std=: Preprocessor Options.
- (line 326)
-* sub_library: Darwin Options. (line 199)
-* sub_umbrella: Darwin Options. (line 199)
-* symbolic: Link Options. (line 157)
-* sysroot: Directory Options. (line 92)
-* T: Link Options. (line 163)
-* target-help <1>: Preprocessor Options.
- (line 644)
-* target-help: Overall Options. (line 240)
-* threads <1>: SPARC Options. (line 230)
-* threads: HPPA Options. (line 205)
-* time: Debugging Options. (line 860)
-* tls: FRV Options. (line 75)
-* TLS: FRV Options. (line 72)
-* traditional <1>: Incompatibilities. (line 6)
-* traditional: C Dialect Options. (line 252)
-* traditional-cpp <1>: Preprocessor Options.
- (line 622)
-* traditional-cpp: C Dialect Options. (line 252)
-* trigraphs <1>: Preprocessor Options.
- (line 626)
-* trigraphs: C Dialect Options. (line 236)
-* twolevel_namespace: Darwin Options. (line 199)
-* u: Link Options. (line 196)
-* U: Preprocessor Options.
- (line 57)
-* umbrella: Darwin Options. (line 199)
-* undef: Preprocessor Options.
- (line 61)
-* undefined: Darwin Options. (line 199)
-* unexported_symbols_list: Darwin Options. (line 199)
-* V: Target Options. (line 25)
-* v <1>: Preprocessor Options.
- (line 648)
-* v: Overall Options. (line 198)
-* version <1>: Preprocessor Options.
- (line 661)
-* version: Overall Options. (line 348)
-* W: Incompatibilities. (line 64)
-* w: Preprocessor Options.
- (line 159)
-* W: Warning Options. (line 146)
-* w: Warning Options. (line 18)
-* Wa: Assembler Options. (line 9)
-* Wabi: C++ Dialect Options.
- (line 286)
-* Waddress: Warning Options. (line 953)
-* Waggregate-return: Warning Options. (line 971)
-* Wall <1>: Standard Libraries. (line 6)
-* Wall <2>: Preprocessor Options.
- (line 81)
-* Wall: Warning Options. (line 99)
-* Warray-bounds: Warning Options. (line 691)
-* Wassign-intercept: Objective-C and Objective-C++ Dialect Options.
- (line 198)
-* Wattributes: Warning Options. (line 976)
-* Wbad-function-cast: Warning Options. (line 869)
-* Wbuiltin-macro-redefined: Warning Options. (line 982)
-* Wcast-align: Warning Options. (line 889)
-* Wcast-qual: Warning Options. (line 884)
-* Wchar-subscripts: Warning Options. (line 184)
-* Wclobbered: Warning Options. (line 909)
-* Wcomment <1>: Preprocessor Options.
- (line 89)
-* Wcomment: Warning Options. (line 189)
-* Wcomments: Preprocessor Options.
- (line 89)
-* Wconversion: Warning Options. (line 913)
-* Wcoverage-mismatch: Language Independent Options.
- (line 42)
-* Wctor-dtor-privacy: C++ Dialect Options.
- (line 378)
-* Wdeclaration-after-statement: Warning Options. (line 812)
-* Wdeprecated: Warning Options. (line 1119)
-* Wdeprecated-declarations: Warning Options. (line 1123)
-* Wdisabled-optimization: Warning Options. (line 1272)
-* Wdiv-by-zero: Warning Options. (line 696)
-* weak_reference_mismatches: Darwin Options. (line 199)
-* Weffc++: C++ Dialect Options.
- (line 405)
-* Wempty-body: Warning Options. (line 932)
-* Wendif-labels <1>: Preprocessor Options.
- (line 136)
-* Wendif-labels: Warning Options. (line 822)
-* Wenum-compare: Warning Options. (line 936)
-* Werror <1>: Preprocessor Options.
- (line 149)
-* Werror: Warning Options. (line 21)
-* Werror=: Warning Options. (line 24)
-* Wextra: Warning Options. (line 146)
-* Wfatal-errors: Warning Options. (line 38)
-* Wfloat-equal: Warning Options. (line 712)
-* Wformat <1>: Function Attributes.
- (line 373)
-* Wformat: Warning Options. (line 194)
-* Wformat-contains-nul: Warning Options. (line 233)
-* Wformat-extra-args: Warning Options. (line 237)
-* Wformat-nonliteral <1>: Function Attributes.
- (line 432)
-* Wformat-nonliteral: Warning Options. (line 255)
-* Wformat-security: Warning Options. (line 260)
-* Wformat-y2k: Warning Options. (line 229)
-* Wformat-zero-length: Warning Options. (line 251)
-* Wformat=2: Warning Options. (line 271)
-* Wframe-larger-than: Warning Options. (line 834)
-* whatsloaded: Darwin Options. (line 199)
-* whyload: Darwin Options. (line 199)
-* Wignored-qualifiers: Warning Options. (line 310)
-* Wimplicit: Warning Options. (line 306)
-* Wimplicit-function-declaration: Warning Options. (line 300)
-* Wimplicit-int: Warning Options. (line 296)
-* Winit-self: Warning Options. (line 283)
-* Winline <1>: Inline. (line 63)
-* Winline: Warning Options. (line 1211)
-* Wint-to-pointer-cast: Warning Options. (line 1238)
-* Winvalid-offsetof: Warning Options. (line 1224)
-* Winvalid-pch: Warning Options. (line 1246)
-* Wl: Link Options. (line 188)
-* Wlarger-than-LEN: Warning Options. (line 831)
-* Wlarger-than=LEN: Warning Options. (line 831)
-* Wlogical-op: Warning Options. (line 966)
-* Wlong-long: Warning Options. (line 1250)
-* Wmain: Warning Options. (line 321)
-* Wmissing-braces: Warning Options. (line 328)
-* Wmissing-declarations: Warning Options. (line 1017)
-* Wmissing-field-initializers: Warning Options. (line 1025)
-* Wmissing-format-attribute: Warning Options. (line 1051)
-* Wmissing-include-dirs: Warning Options. (line 338)
-* Wmissing-noreturn: Warning Options. (line 1043)
-* Wmissing-parameter-type: Warning Options. (line 1003)
-* Wmissing-prototypes: Warning Options. (line 1011)
-* Wmultichar: Warning Options. (line 1070)
-* Wnested-externs: Warning Options. (line 1186)
-* Wno-abi: C++ Dialect Options.
- (line 286)
-* Wno-address: Warning Options. (line 953)
-* Wno-aggregate-return: Warning Options. (line 971)
-* Wno-all: Warning Options. (line 99)
-* Wno-array-bounds: Warning Options. (line 691)
-* Wno-assign-intercept: Objective-C and Objective-C++ Dialect Options.
- (line 198)
-* Wno-attributes: Warning Options. (line 976)
-* Wno-bad-function-cast: Warning Options. (line 869)
-* Wno-builtin-macro-redefined: Warning Options. (line 982)
-* Wno-cast-align: Warning Options. (line 889)
-* Wno-cast-qual: Warning Options. (line 884)
-* Wno-char-subscripts: Warning Options. (line 184)
-* Wno-clobbered: Warning Options. (line 909)
-* Wno-comment: Warning Options. (line 189)
-* Wno-conversion: Warning Options. (line 913)
-* Wno-ctor-dtor-privacy: C++ Dialect Options.
- (line 378)
-* Wno-declaration-after-statement: Warning Options. (line 812)
-* Wno-deprecated: Warning Options. (line 1119)
-* Wno-deprecated-declarations: Warning Options. (line 1123)
-* Wno-disabled-optimization: Warning Options. (line 1272)
-* Wno-div-by-zero: Warning Options. (line 696)
-* Wno-effc++: C++ Dialect Options.
- (line 405)
-* Wno-empty-body: Warning Options. (line 932)
-* Wno-endif-labels: Warning Options. (line 822)
-* Wno-enum-compare: Warning Options. (line 936)
-* Wno-error: Warning Options. (line 21)
-* Wno-error=: Warning Options. (line 24)
-* Wno-extra: Warning Options. (line 146)
-* Wno-fatal-errors: Warning Options. (line 38)
-* Wno-float-equal: Warning Options. (line 712)
-* Wno-format: Warning Options. (line 194)
-* Wno-format-contains-nul: Warning Options. (line 233)
-* Wno-format-extra-args: Warning Options. (line 237)
-* Wno-format-nonliteral: Warning Options. (line 255)
-* Wno-format-security: Warning Options. (line 260)
-* Wno-format-y2k: Warning Options. (line 229)
-* Wno-format-zero-length: Warning Options. (line 251)
-* Wno-format=2: Warning Options. (line 271)
-* Wno-ignored-qualifiers: Warning Options. (line 310)
-* Wno-implicit: Warning Options. (line 306)
-* Wno-implicit-function-declaration: Warning Options. (line 300)
-* Wno-implicit-int: Warning Options. (line 296)
-* Wno-init-self: Warning Options. (line 283)
-* Wno-inline: Warning Options. (line 1211)
-* Wno-int-to-pointer-cast: Warning Options. (line 1238)
-* Wno-invalid-offsetof: Warning Options. (line 1224)
-* Wno-invalid-pch: Warning Options. (line 1246)
-* Wno-logical-op: Warning Options. (line 966)
-* Wno-long-long: Warning Options. (line 1250)
-* Wno-main: Warning Options. (line 321)
-* Wno-missing-braces: Warning Options. (line 328)
-* Wno-missing-declarations: Warning Options. (line 1017)
-* Wno-missing-field-initializers: Warning Options. (line 1025)
-* Wno-missing-format-attribute: Warning Options. (line 1051)
-* Wno-missing-include-dirs: Warning Options. (line 338)
-* Wno-missing-noreturn: Warning Options. (line 1043)
-* Wno-missing-parameter-type: Warning Options. (line 1003)
-* Wno-missing-prototypes: Warning Options. (line 1011)
-* Wno-mudflap: Warning Options. (line 1292)
-* Wno-multichar: Warning Options. (line 1070)
-* Wno-nested-externs: Warning Options. (line 1186)
-* Wno-non-template-friend: C++ Dialect Options.
- (line 442)
-* Wno-non-virtual-dtor: C++ Dialect Options.
- (line 383)
-* Wno-nonnull: Warning Options. (line 276)
-* Wno-old-style-cast: C++ Dialect Options.
- (line 458)
-* Wno-old-style-declaration: Warning Options. (line 993)
-* Wno-old-style-definition: Warning Options. (line 999)
-* Wno-overflow: Warning Options. (line 1129)
-* Wno-overlength-strings: Warning Options. (line 1296)
-* Wno-overloaded-virtual: C++ Dialect Options.
- (line 464)
-* Wno-override-init: Warning Options. (line 1132)
-* Wno-packed: Warning Options. (line 1140)
-* Wno-packed-bitfield-compat: Warning Options. (line 1157)
-* Wno-padded: Warning Options. (line 1174)
-* Wno-parentheses: Warning Options. (line 341)
-* Wno-pedantic-ms-format: Warning Options. (line 849)
-* Wno-pmf-conversions <1>: Bound member functions.
- (line 35)
-* Wno-pmf-conversions: C++ Dialect Options.
- (line 483)
-* Wno-pointer-arith: Warning Options. (line 855)
-* Wno-pointer-sign: Warning Options. (line 1281)
-* Wno-pointer-to-int-cast: Warning Options. (line 1242)
-* Wno-pragmas: Warning Options. (line 594)
-* Wno-protocol: Objective-C and Objective-C++ Dialect Options.
- (line 202)
-* Wno-redundant-decls: Warning Options. (line 1181)
-* Wno-reorder: C++ Dialect Options.
- (line 389)
-* Wno-return-type: Warning Options. (line 431)
-* Wno-selector: Objective-C and Objective-C++ Dialect Options.
- (line 212)
-* Wno-sequence-point: Warning Options. (line 385)
-* Wno-shadow: Warning Options. (line 826)
-* Wno-sign-compare: Warning Options. (line 940)
-* Wno-sign-conversion: Warning Options. (line 947)
-* Wno-sign-promo: C++ Dialect Options.
- (line 487)
-* Wno-stack-protector: Warning Options. (line 1287)
-* Wno-strict-aliasing: Warning Options. (line 599)
-* Wno-strict-aliasing=n: Warning Options. (line 607)
-* Wno-strict-null-sentinel: C++ Dialect Options.
- (line 435)
-* Wno-strict-overflow: Warning Options. (line 640)
-* Wno-strict-prototypes: Warning Options. (line 987)
-* Wno-strict-selector-match: Objective-C and Objective-C++ Dialect Options.
- (line 224)
-* Wno-switch: Warning Options. (line 446)
-* Wno-switch-default: Warning Options. (line 454)
-* Wno-switch-enum: Warning Options. (line 457)
-* Wno-sync-nand: Warning Options. (line 463)
-* Wno-system-headers: Warning Options. (line 701)
-* Wno-traditional: Warning Options. (line 727)
-* Wno-traditional-conversion: Warning Options. (line 804)
-* Wno-trigraphs: Warning Options. (line 468)
-* Wno-type-limits: Warning Options. (line 862)
-* Wno-undeclared-selector: Objective-C and Objective-C++ Dialect Options.
- (line 232)
-* Wno-undef: Warning Options. (line 819)
-* Wno-uninitialized: Warning Options. (line 517)
-* Wno-unknown-pragmas: Warning Options. (line 587)
-* Wno-unreachable-code: Warning Options. (line 1189)
-* Wno-unsafe-loop-optimizations: Warning Options. (line 843)
-* Wno-unused: Warning Options. (line 510)
-* Wno-unused-function: Warning Options. (line 473)
-* Wno-unused-label: Warning Options. (line 478)
-* Wno-unused-parameter: Warning Options. (line 485)
-* Wno-unused-value: Warning Options. (line 500)
-* Wno-unused-variable: Warning Options. (line 492)
-* Wno-variadic-macros: Warning Options. (line 1256)
-* Wno-vla: Warning Options. (line 1262)
-* Wno-volatile-register-var: Warning Options. (line 1266)
-* Wno-write-strings: Warning Options. (line 895)
-* Wnon-template-friend: C++ Dialect Options.
- (line 442)
-* Wnon-virtual-dtor: C++ Dialect Options.
- (line 383)
-* Wnonnull: Warning Options. (line 276)
-* Wnormalized=: Warning Options. (line 1076)
-* Wold-style-cast: C++ Dialect Options.
- (line 458)
-* Wold-style-declaration: Warning Options. (line 993)
-* Wold-style-definition: Warning Options. (line 999)
-* Woverflow: Warning Options. (line 1129)
-* Woverlength-strings: Warning Options. (line 1296)
-* Woverloaded-virtual: C++ Dialect Options.
- (line 464)
-* Woverride-init: Warning Options. (line 1132)
-* Wp: Preprocessor Options.
- (line 14)
-* Wpacked: Warning Options. (line 1140)
-* Wpacked-bitfield-compat: Warning Options. (line 1157)
-* Wpadded: Warning Options. (line 1174)
-* Wparentheses: Warning Options. (line 341)
-* Wpedantic-ms-format: Warning Options. (line 849)
-* Wpmf-conversions: C++ Dialect Options.
- (line 483)
-* Wpointer-arith <1>: Pointer Arith. (line 13)
-* Wpointer-arith: Warning Options. (line 855)
-* Wpointer-sign: Warning Options. (line 1281)
-* Wpointer-to-int-cast: Warning Options. (line 1242)
-* Wpragmas: Warning Options. (line 594)
-* Wprotocol: Objective-C and Objective-C++ Dialect Options.
- (line 202)
-* wrapper: Overall Options. (line 351)
-* Wredundant-decls: Warning Options. (line 1181)
-* Wreorder: C++ Dialect Options.
- (line 389)
-* Wreturn-type: Warning Options. (line 431)
-* Wselector: Objective-C and Objective-C++ Dialect Options.
- (line 212)
-* Wsequence-point: Warning Options. (line 385)
-* Wshadow: Warning Options. (line 826)
-* Wsign-compare: Warning Options. (line 940)
-* Wsign-conversion: Warning Options. (line 947)
-* Wsign-promo: C++ Dialect Options.
- (line 487)
-* Wstack-protector: Warning Options. (line 1287)
-* Wstrict-aliasing: Warning Options. (line 599)
-* Wstrict-aliasing=n: Warning Options. (line 607)
-* Wstrict-null-sentinel: C++ Dialect Options.
- (line 435)
-* Wstrict-overflow: Warning Options. (line 640)
-* Wstrict-prototypes: Warning Options. (line 987)
-* Wstrict-selector-match: Objective-C and Objective-C++ Dialect Options.
- (line 224)
-* Wswitch: Warning Options. (line 446)
-* Wswitch-default: Warning Options. (line 454)
-* Wswitch-enum: Warning Options. (line 457)
-* Wsync-nand: Warning Options. (line 463)
-* Wsystem-headers <1>: Preprocessor Options.
- (line 153)
-* Wsystem-headers: Warning Options. (line 701)
-* Wtraditional <1>: Preprocessor Options.
- (line 106)
-* Wtraditional: Warning Options. (line 727)
-* Wtraditional-conversion <1>: Protoize Caveats. (line 31)
-* Wtraditional-conversion: Warning Options. (line 804)
-* Wtrigraphs <1>: Preprocessor Options.
- (line 94)
-* Wtrigraphs: Warning Options. (line 468)
-* Wtype-limits: Warning Options. (line 862)
-* Wundeclared-selector: Objective-C and Objective-C++ Dialect Options.
- (line 232)
-* Wundef <1>: Preprocessor Options.
- (line 112)
-* Wundef: Warning Options. (line 819)
-* Wuninitialized: Warning Options. (line 517)
-* Wunknown-pragmas: Warning Options. (line 587)
-* Wunreachable-code: Warning Options. (line 1189)
-* Wunsafe-loop-optimizations: Warning Options. (line 843)
-* Wunused: Warning Options. (line 510)
-* Wunused-function: Warning Options. (line 473)
-* Wunused-label: Warning Options. (line 478)
-* Wunused-macros: Preprocessor Options.
- (line 117)
-* Wunused-parameter: Warning Options. (line 485)
-* Wunused-value: Warning Options. (line 500)
-* Wunused-variable: Warning Options. (line 492)
-* Wvariadic-macros: Warning Options. (line 1256)
-* Wvla: Warning Options. (line 1262)
-* Wvolatile-register-var: Warning Options. (line 1266)
-* Wwrite-strings: Warning Options. (line 895)
-* x <1>: Preprocessor Options.
- (line 310)
-* x: Overall Options. (line 122)
-* Xassembler: Assembler Options. (line 13)
-* Xbind-lazy: VxWorks Options. (line 26)
-* Xbind-now: VxWorks Options. (line 30)
-* Xlinker: Link Options. (line 169)
-* Xpreprocessor: Preprocessor Options.
- (line 25)
-* Ym: System V Options. (line 26)
-* YP: System V Options. (line 22)
-
-\1f
-File: gcc.info, Node: Keyword Index, Prev: Option Index, Up: Top
-
-Keyword Index
-*************
-
-\0\b[index\0\b]
-* 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 1344)
-* $: Dollar Signs. (line 6)
-* % in constraint: Modifiers. (line 45)
-* %include: Spec Files. (line 27)
-* %include_noerr: Spec Files. (line 31)
-* %rename: Spec Files. (line 35)
-* & in constraint: Modifiers. (line 25)
-* ': Incompatibilities. (line 116)
-* (: Constructing Calls. (line 53)
-* * in constraint: Modifiers. (line 62)
-* + in constraint: Modifiers. (line 12)
-* -lgcc, use with -nodefaultlibs: Link Options. (line 79)
-* -lgcc, use with -nostdlib: Link Options. (line 79)
-* -nodefaultlibs and unresolved references: Link Options. (line 79)
-* -nostdlib and unresolved references: Link Options. (line 79)
-* .sdata/.sdata2 references (PowerPC): RS/6000 and PowerPC Options.
- (line 663)
-* //: C++ Comments. (line 6)
-* 0 in constraint: Simple Constraints. (line 117)
-* < in constraint: Simple Constraints. (line 48)
-* = in constraint: Modifiers. (line 8)
-* > in constraint: Simple Constraints. (line 52)
-* ? in constraint: Multi-Alternative. (line 27)
-* ?: extensions: Conditionals. (line 6)
-* ?: side effect: Conditionals. (line 20)
-* _ in variables in macros: Typeof. (line 42)
-* __builtin___clear_cache: Other Builtins. (line 274)
-* __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)
-* __builtin_apply: Constructing Calls. (line 31)
-* __builtin_apply_args: Constructing Calls. (line 20)
-* __builtin_bswap32: Other Builtins. (line 493)
-* __builtin_bswap64: Other Builtins. (line 498)
-* __builtin_choose_expr: Other Builtins. (line 156)
-* __builtin_clz: Other Builtins. (line 426)
-* __builtin_clzl: Other Builtins. (line 444)
-* __builtin_clzll: Other Builtins. (line 464)
-* __builtin_constant_p: Other Builtins. (line 196)
-* __builtin_ctz: Other Builtins. (line 430)
-* __builtin_ctzl: Other Builtins. (line 448)
-* __builtin_ctzll: Other Builtins. (line 468)
-* __builtin_expect: Other Builtins. (line 242)
-* __builtin_ffs: Other Builtins. (line 422)
-* __builtin_ffsl: Other Builtins. (line 440)
-* __builtin_ffsll: Other Builtins. (line 460)
-* __builtin_fpclassify: Other Builtins. (line 6)
-* __builtin_frame_address: Return Address. (line 34)
-* __builtin_huge_val: Other Builtins. (line 325)
-* __builtin_huge_valf: Other Builtins. (line 330)
-* __builtin_huge_vall: Other Builtins. (line 333)
-* __builtin_inf: Other Builtins. (line 348)
-* __builtin_infd128: Other Builtins. (line 358)
-* __builtin_infd32: Other Builtins. (line 352)
-* __builtin_infd64: Other Builtins. (line 355)
-* __builtin_inff: Other Builtins. (line 362)
-* __builtin_infl: Other Builtins. (line 367)
-* __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_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_nan: Other Builtins. (line 378)
-* __builtin_nand128: Other Builtins. (line 400)
-* __builtin_nand32: Other Builtins. (line 394)
-* __builtin_nand64: Other Builtins. (line 397)
-* __builtin_nanf: Other Builtins. (line 404)
-* __builtin_nanl: Other Builtins. (line 407)
-* __builtin_nans: Other Builtins. (line 411)
-* __builtin_nansf: Other Builtins. (line 415)
-* __builtin_nansl: Other Builtins. (line 418)
-* __builtin_object_size: Object Size Checking.
- (line 6)
-* __builtin_offsetof: Offsetof. (line 6)
-* __builtin_parity: Other Builtins. (line 437)
-* __builtin_parityl: Other Builtins. (line 456)
-* __builtin_parityll: Other Builtins. (line 476)
-* __builtin_popcount: Other Builtins. (line 434)
-* __builtin_popcountl: Other Builtins. (line 452)
-* __builtin_popcountll: Other Builtins. (line 472)
-* __builtin_powi: Other Builtins. (line 6)
-* __builtin_powif: Other Builtins. (line 6)
-* __builtin_powil: Other Builtins. (line 6)
-* __builtin_prefetch: Other Builtins. (line 286)
-* __builtin_return: Constructing Calls. (line 48)
-* __builtin_return_address: Return Address. (line 11)
-* __builtin_trap: Other Builtins. (line 266)
-* __builtin_types_compatible_p: Other Builtins. (line 110)
-* __complex__ keyword: Complex. (line 6)
-* __declspec(dllexport): Function Attributes.
- (line 244)
-* __declspec(dllimport): Function Attributes.
- (line 274)
-* __extension__: Alternate Keywords. (line 29)
-* __float128 data type: Floating Types. (line 6)
-* __float80 data type: Floating Types. (line 6)
-* __func__ identifier: Function Names. (line 6)
-* __FUNCTION__ identifier: Function Names. (line 6)
-* __imag__ keyword: Complex. (line 27)
-* __PRETTY_FUNCTION__ identifier: Function Names. (line 6)
-* __real__ keyword: Complex. (line 27)
-* __STDC_HOSTED__: Standards. (line 13)
-* __sync_add_and_fetch: Atomic Builtins. (line 61)
-* __sync_and_and_fetch: Atomic Builtins. (line 61)
-* __sync_bool_compare_and_swap: Atomic Builtins. (line 73)
-* __sync_fetch_and_add: Atomic Builtins. (line 45)
-* __sync_fetch_and_and: Atomic Builtins. (line 45)
-* __sync_fetch_and_nand: Atomic Builtins. (line 45)
-* __sync_fetch_and_or: Atomic Builtins. (line 45)
-* __sync_fetch_and_sub: Atomic Builtins. (line 45)
-* __sync_fetch_and_xor: Atomic Builtins. (line 45)
-* __sync_lock_release: Atomic Builtins. (line 103)
-* __sync_lock_test_and_set: Atomic Builtins. (line 85)
-* __sync_nand_and_fetch: Atomic Builtins. (line 61)
-* __sync_or_and_fetch: Atomic Builtins. (line 61)
-* __sync_sub_and_fetch: Atomic Builtins. (line 61)
-* __sync_synchronize: Atomic Builtins. (line 82)
-* __sync_val_compare_and_swap: Atomic Builtins. (line 73)
-* __sync_xor_and_fetch: Atomic Builtins. (line 61)
-* __thread: Thread-Local. (line 6)
-* _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)
-* _Sat data type: Fixed-Point. (line 6)
-* ABI: Compatibility. (line 6)
-* abort: Other Builtins. (line 6)
-* abs: Other Builtins. (line 6)
-* accessing volatiles: 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)
-* additional floating types: Floating Types. (line 6)
-* address constraints: Simple Constraints. (line 144)
-* address of a label: Labels as Values. (line 6)
-* address_operand: Simple Constraints. (line 148)
-* alias attribute: Function Attributes.
- (line 34)
-* aliasing of parameters: Code Gen Options. (line 409)
-* aligned attribute <1>: Type Attributes. (line 31)
-* aligned attribute <2>: Variable Attributes.
- (line 23)
-* aligned attribute: Function Attributes.
- (line 47)
-* alignment: Alignment. (line 6)
-* alloc_size attribute: Function Attributes.
- (line 67)
-* alloca: Other Builtins. (line 6)
-* alloca vs variable-length arrays: Variable Length. (line 27)
-* Allow nesting in an interrupt handler on the Blackfin processor.: Function Attributes.
- (line 701)
-* alternate keywords: Alternate Keywords. (line 6)
-* always_inline function attribute: Function Attributes.
- (line 88)
-* 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 [Annotated C++ Reference Manual]: Backwards Compatibility.
- (line 6)
-* ARM options: ARM Options. (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 131)
-* 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)
-* 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 492)
-* 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)
-* bounds checking: Optimize Options. (line 338)
-* bug criteria: Bug Criteria. (line 6)
-* bugs: Bugs. (line 6)
-* bugs, known: Trouble. (line 6)
-* built-in functions <1>: Other Builtins. (line 6)
-* built-in functions: C Dialect Options. (line 170)
-* 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 250)
-* 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)
-* C89: Standards. (line 13)
-* C90: Standards. (line 13)
-* C94: Standards. (line 13)
-* C95: Standards. (line 13)
-* C99: Standards. (line 13)
-* C9X: Standards. (line 13)
-* C_INCLUDE_PATH: Environment Variables.
- (line 127)
-* 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)
-* calling functions through the function vector on H8/300, M16C, M32C and SH2A processors: Function Attributes.
- (line 471)
-* calloc: Other Builtins. (line 6)
-* 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 496)
-* character set, input: Preprocessor Options.
- (line 509)
-* character set, input normalization: Warning Options. (line 1076)
-* character set, wide execution: Preprocessor Options.
- (line 501)
-* 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 852)
-* command options: Invoking GCC. (line 6)
-* comments, C++ style: C++ Comments. (line 6)
-* common attribute: Variable Attributes.
- (line 105)
-* comparison of signed and unsigned values, warning: Warning Options.
- (line 940)
-* 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 88)
-* 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 176)
-* constants in constraints: Simple Constraints. (line 60)
-* constraint modifier characters: Modifiers. (line 6)
-* constraint, matching: Simple Constraints. (line 129)
-* 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 204)
-* 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 126)
-* CPLUS_INCLUDE_PATH: Environment Variables.
- (line 128)
-* 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)
-* creal: Other Builtins. (line 6)
-* crealf: Other Builtins. (line 6)
-* creall: Other Builtins. (line 6)
-* CRIS Options: CRIS Options. (line 6)
-* cross compiling: Target Options. (line 6)
-* CRX Options: CRX 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)
-* 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 23)
-* 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 154)
-* dependencies, make: Preprocessor Options.
- (line 173)
-* DEPENDENCIES_OUTPUT: Environment Variables.
- (line 153)
-* dependent name lookup: Name lookup. (line 6)
-* deprecated attribute: Variable Attributes.
- (line 113)
-* deprecated attribute.: Function Attributes.
- (line 226)
-* designated initializers: Designated Inits. (line 6)
-* designator lists: Designated Inits. (line 94)
-* designators: Designated Inits. (line 61)
-* destructor function attribute: Function Attributes.
- (line 204)
-* 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 117)
-* directory options: Directory Options. (line 6)
-* 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 79)
-* earlyclobber operand: Modifiers. (line 25)
-* eight bit data on the H8/300, H8/300H, and H8S: Function Attributes.
- (line 327)
-* empty structures: Empty Structures. (line 6)
-* 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 145)
-* error messages: Warnings and Errors.
- (line 6)
-* escaped newlines: Escaped Newlines. (line 6)
-* exception handler functions on the Blackfin processor: Function Attributes.
- (line 337)
-* 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 153)
-* 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 343)
-* F in constraint: Simple Constraints. (line 84)
-* 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 138)
-* flexible array members: Zero Length. (line 6)
-* float as function value type: Incompatibilities. (line 141)
-* floating point precision <1>: Disappointments. (line 68)
-* floating point precision: Optimize Options. (line 1352)
-* 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 894)
-* format function attribute: Function Attributes.
- (line 373)
-* format_arg function attribute: Function Attributes.
- (line 432)
-* Fortran: G++ and GCC. (line 6)
-* 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 643)
-* function attributes: Function Attributes.
- (line 6)
-* function pointers, arithmetic: Pointer Arith. (line 6)
-* function prototype declarations: Function Prototypes.
- (line 6)
-* function without a prologue/epilogue code: Function Attributes.
- (line 683)
-* function, size of pointer to: Pointer Arith. (line 6)
-* functions called via pointer on the RS/6000 and PowerPC: Function Attributes.
- (line 597)
-* functions in arbitrary sections: Function Attributes.
- (line 6)
-* functions that are passed arguments in registers on the 386: Function Attributes.
- (line 6)
-* functions that behave like malloc: Function Attributes.
- (line 6)
-* 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 170)
-* 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 return more than once: Function Attributes.
- (line 6)
-* functions which do not handle memory bank switching on 68HC11/68HC12: Function Attributes.
- (line 695)
-* functions which handle memory bank switching: Function Attributes.
- (line 348)
-* 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 110)
-* G in constraint: Simple Constraints. (line 88)
-* g++: Invoking G++. (line 14)
-* G++: G++ and GCC. (line 30)
-* gamma: Other Builtins. (line 6)
-* gamma_r: 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)
-* GCC: G++ and GCC. (line 6)
-* GCC command options: Invoking GCC. (line 6)
-* GCC_EXEC_PREFIX: Environment Variables.
- (line 52)
-* gcc_struct: Type Attributes. (line 309)
-* gcc_struct attribute: Variable Attributes.
- (line 349)
-* gcov: Debugging Options. (line 263)
-* gettext: Other Builtins. (line 6)
-* global offset table: Code Gen Options. (line 184)
-* global register after longjmp: Global Reg Vars. (line 66)
-* 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 93)
-* goto with computed label: Labels as Values. (line 6)
-* gprof: Debugging Options. (line 224)
-* grouping options: Invoking GCC. (line 26)
-* H in constraint: Simple Constraints. (line 88)
-* hardware models and configurations, specifying: Submodel Options.
- (line 6)
-* hex floats: Hex Floats. (line 6)
-* HK fixed-suffix: Fixed-Point. (line 6)
-* hk fixed-suffix: Fixed-Point. (line 6)
-* hosted environment <1>: C Dialect Options. (line 204)
-* hosted environment: Standards. (line 13)
-* hosted implementation: Standards. (line 13)
-* hot function attribute: Function Attributes.
- (line 839)
-* 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 71)
-* i in constraint: Simple Constraints. (line 60)
-* 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)
-* 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)
-* 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 ARM: Function Attributes.
- (line 587)
-* indirect calls on MIPS: Function Attributes.
- (line 609)
-* init_priority attribute: C++ Attributes. (line 9)
-* initializations in expressions: Compound Literals. (line 6)
-* initializers with labeled elements: Designated Inits. (line 6)
-* initializers, non-constant: Initializers. (line 6)
-* 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 532)
-* interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors: Function Attributes.
- (line 557)
-* interrupt service routines on ARM: Function Attributes.
- (line 572)
-* interrupt thread functions on fido: Function Attributes.
- (line 564)
-* 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 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 29)
-* 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)
-* keywords, alternate: Alternate Keywords. (line 6)
-* known causes of trouble: Trouble. (line 6)
-* l1_data variable attribute: Variable Attributes.
- (line 317)
-* l1_data_A variable attribute: Variable Attributes.
- (line 317)
-* l1_data_B variable attribute: Variable Attributes.
- (line 317)
-* l1_text function attribute: Function Attributes.
- (line 581)
-* 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)
-* 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)
-* length-zero arrays: Zero Length. (line 6)
-* lgamma: Other Builtins. (line 6)
-* lgamma_r: 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)
-* Libraries: Link Options. (line 24)
-* LIBRARY_PATH: Environment Variables.
- (line 94)
-* link options: Link Options. (line 6)
-* linker script: Link Options. (line 163)
-* 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)
-* load address instruction: Simple Constraints. (line 144)
-* local labels: Local Labels. (line 6)
-* local variables in macros: Typeof. (line 42)
-* local variables, specifying registers: Local Reg Vars. (line 6)
-* locale: Environment Variables.
- (line 21)
-* locale definition: Environment Variables.
- (line 103)
-* 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 66)
-* longjmp incompatibilities: Incompatibilities. (line 39)
-* longjmp warnings: Warning Options. (line 570)
-* 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)
-* M68hc1x options: M68hc1x 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 241)
-* macros, inline alternative: Inline. (line 6)
-* macros, local labels: Local Labels. (line 6)
-* macros, local variables in: Typeof. (line 42)
-* macros, statements in expressions: Statement Exprs. (line 6)
-* macros, types of arguments: Typeof. (line 6)
-* make: Preprocessor Options.
- (line 173)
-* malloc: Other Builtins. (line 6)
-* malloc attribute: Function Attributes.
- (line 619)
-* matching constraint: Simple Constraints. (line 129)
-* 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)
-* 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)
-* middle-operands, omitted: Conditionals. (line 6)
-* MIPS options: MIPS Options. (line 6)
-* mips16 attribute: Function Attributes.
- (line 629)
-* 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 131)
-* modf: Other Builtins. (line 6)
-* modff: Other Builtins. (line 6)
-* modfl: Other Builtins. (line 6)
-* modifiers in constraints: Modifiers. (line 6)
-* ms_abi attribute: Function Attributes.
- (line 671)
-* ms_struct: Type Attributes. (line 309)
-* ms_struct attribute: Variable Attributes.
- (line 349)
-* mudflap: Optimize Options. (line 338)
-* multiple alternative constraints: Multi-Alternative. (line 6)
-* multiprecision arithmetic: Long Long. (line 6)
-* n in constraint: Simple Constraints. (line 65)
-* names used in assembler code: Asm Labels. (line 6)
-* naming convention, implementation headers: C++ Interface. (line 46)
-* nearbyint: Other Builtins. (line 6)
-* nearbyintf: Other Builtins. (line 6)
-* nearbyintl: Other Builtins. (line 6)
-* nested functions: Nested Functions. (line 6)
-* 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 1076)
-* NFKC: Warning Options. (line 1076)
-* NMI handler functions on the Blackfin processor: Function Attributes.
- (line 706)
-* no_instrument_function function attribute: Function Attributes.
- (line 712)
-* nocommon attribute: Variable Attributes.
- (line 105)
-* noinline function attribute: Function Attributes.
- (line 717)
-* nomips16 attribute: Function Attributes.
- (line 629)
-* non-constant initializers: Initializers. (line 6)
-* non-static inline function: Inline. (line 85)
-* nonnull function attribute: Function Attributes.
- (line 727)
-* noreturn function attribute: Function Attributes.
- (line 750)
-* nothrow function attribute: Function Attributes.
- (line 792)
-* o in constraint: Simple Constraints. (line 23)
-* OBJC_INCLUDE_PATH: Environment Variables.
- (line 129)
-* Objective-C <1>: Standards. (line 153)
-* Objective-C: G++ and GCC. (line 6)
-* Objective-C and Objective-C++ options, command line: Objective-C and Objective-C++ Dialect Options.
- (line 6)
-* Objective-C++ <1>: Standards. (line 153)
-* Objective-C++: G++ and GCC. (line 6)
-* 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 221)
-* operand constraints, asm: Constraints. (line 6)
-* optimize function attribute: Function Attributes.
- (line 800)
-* 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)
-* other register constraints: Simple Constraints. (line 153)
-* output file option: Overall Options. (line 186)
-* overloaded virtual fn, warning: C++ Dialect Options.
- (line 464)
-* p in constraint: Simple Constraints. (line 144)
-* packed attribute: Variable Attributes.
- (line 142)
-* parameter forward declaration: Variable Length. (line 60)
-* parameters, aliased: Code Gen Options. (line 409)
-* Pascal: G++ and GCC. (line 23)
-* PDP-11 Options: PDP-11 Options. (line 6)
-* PIC: Code Gen Options. (line 184)
-* picoChip options: picoChip Options. (line 6)
-* pmf: Bound member functions.
- (line 6)
-* pointer arguments: Function Attributes.
- (line 181)
-* 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 optimize: Function Specific Option Pragmas.
- (line 20)
-* pragma GCC pop_options: Function Specific Option Pragmas.
- (line 33)
-* pragma GCC push_options: Function Specific Option Pragmas.
- (line 33)
-* pragma GCC reset_options: Function Specific Option Pragmas.
- (line 43)
-* pragma GCC target: Function Specific Option Pragmas.
- (line 7)
-* pragma, align: Solaris Pragmas. (line 11)
-* pragma, diagnostic: Diagnostic Pragmas. (line 14)
-* pragma, extern_prefix: Symbol-Renaming Pragmas.
- (line 19)
-* pragma, fini: Solaris Pragmas. (line 19)
-* pragma, init: Solaris Pragmas. (line 24)
-* pragma, long_calls: ARM Pragmas. (line 11)
-* pragma, long_calls_off: ARM Pragmas. (line 17)
-* pragma, longcall: RS/6000 and PowerPC Pragmas.
- (line 14)
-* 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 1344)
-* pragma, redefine_extname: Symbol-Renaming Pragmas.
- (line 14)
-* 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 587)
-* 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 218)
-* progmem variable attribute: Variable Attributes.
- (line 503)
-* promotion of formal parameters: Function Prototypes.
- (line 6)
-* pure function attribute: Function Attributes.
- (line 817)
-* push address instruction: Simple Constraints. (line 144)
-* 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 42)
-* question mark: Multi-Alternative. (line 27)
-* R fixed-suffix: Fixed-Point. (line 6)
-* r fixed-suffix: Fixed-Point. (line 6)
-* r in constraint: Simple Constraints. (line 56)
-* ranges in case statements: Case Ranges. (line 6)
-* read-only strings: Incompatibilities. (line 9)
-* register variable after longjmp: Global Reg Vars. (line 66)
-* registers: Extended Asm. (line 6)
-* registers for local variables: Local Reg Vars. (line 6)
-* registers in constraints: Simple Constraints. (line 56)
-* registers, global allocation: Explicit Reg Vars. (line 6)
-* registers, global variables in: Global Reg Vars. (line 6)
-* regparm attribute: Function Attributes.
- (line 870)
-* relocation truncated to fit (ColdFire): M680x0 Options. (line 325)
-* relocation truncated to fit (MIPS): MIPS Options. (line 198)
-* 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)
-* reordering, warning: C++ Dialect Options.
- (line 389)
-* reporting bugs: Bugs. (line 6)
-* resbank attribute: Function Attributes.
- (line 902)
-* 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_twice attribute: Function Attributes.
- (line 916)
-* rindex: Other Builtins. (line 6)
-* rint: Other Builtins. (line 6)
-* rintf: Other Builtins. (line 6)
-* rintl: Other Builtins. (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 43)
-* run-time options: Code Gen Options. (line 6)
-* s in constraint: Simple Constraints. (line 92)
-* 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 925)
-* 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)
-* 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 23)
-* 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 930)
-* section variable attribute: Variable Attributes.
- (line 163)
-* sentinel function attribute: Function Attributes.
- (line 946)
-* setjmp: Global Reg Vars. (line 66)
-* setjmp incompatibilities: Incompatibilities. (line 39)
-* shared strings: Incompatibilities. (line 9)
-* shared variable attribute: Variable Attributes.
- (line 208)
-* side effect in ?:: Conditionals. (line 20)
-* side effects, macro argument: Statement Exprs. (line 35)
-* side effects, order of evaluation: Non-bugs. (line 196)
-* signal handler functions on the AVR processors: Function Attributes.
- (line 977)
-* 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 940)
-* significand: Other Builtins. (line 6)
-* significandf: Other Builtins. (line 6)
-* significandl: Other Builtins. (line 6)
-* 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 (PowerPC): RS/6000 and PowerPC Options.
- (line 663)
-* snprintf: Other Builtins. (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)
-* 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 887)
-* 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)
-* 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 169)
-* 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 999)
-* system headers, warnings from: Warning Options. (line 701)
-* sysv_abi attribute: Function Attributes.
- (line 671)
-* 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 1006)
-* target machine, specifying: Target Options. (line 6)
-* target options: Target Options. (line 6)
-* target("abm") attribute: Function Attributes.
- (line 1033)
-* target("aes") attribute: Function Attributes.
- (line 1038)
-* target("align-stringops") attribute: Function Attributes.
- (line 1120)
-* target("arch=ARCH") attribute: Function Attributes.
- (line 1129)
-* target("cld") attribute: Function Attributes.
- (line 1091)
-* target("fancy-math-387") attribute: Function Attributes.
- (line 1095)
-* target("fpmath=FPMATH") attribute: Function Attributes.
- (line 1137)
-* target("fused-madd") attribute: Function Attributes.
- (line 1100)
-* target("ieee-fp") attribute: Function Attributes.
- (line 1105)
-* target("inline-all-stringops") attribute: Function Attributes.
- (line 1110)
-* target("inline-stringops-dynamically") attribute: Function Attributes.
- (line 1114)
-* target("mmx") attribute: Function Attributes.
- (line 1042)
-* target("pclmul") attribute: Function Attributes.
- (line 1046)
-* target("popcnt") attribute: Function Attributes.
- (line 1050)
-* target("recip") attribute: Function Attributes.
- (line 1124)
-* target("sse") attribute: Function Attributes.
- (line 1054)
-* target("sse2") attribute: Function Attributes.
- (line 1058)
-* target("sse3") attribute: Function Attributes.
- (line 1062)
-* target("sse4") attribute: Function Attributes.
- (line 1066)
-* target("sse4.1") attribute: Function Attributes.
- (line 1071)
-* target("sse4.2") attribute: Function Attributes.
- (line 1075)
-* target("sse4a") attribute: Function Attributes.
- (line 1079)
-* target("sse5") attribute: Function Attributes.
- (line 1083)
-* target("ssse3") attribute: Function Attributes.
- (line 1087)
-* target("tune=TUNE") attribute: Function Attributes.
- (line 1133)
-* 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)
-* tiny data section on the H8/300H and H8S: Function Attributes.
- (line 1155)
-* TLS: Thread-Local. (line 6)
-* tls_model attribute: Variable Attributes.
- (line 232)
-* 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 250)
-* 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)
-* type_info: Vague Linkage. (line 43)
-* typedef names as function parameters: Incompatibilities. (line 97)
-* typeof: Typeof. (line 6)
-* 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 42)
-* union: Unnamed Fields. (line 6)
-* union, casting to a: Cast to Union. (line 6)
-* unions: Incompatibilities. (line 146)
-* unknown pragmas, warning: Warning Options. (line 587)
-* unresolved references and -nodefaultlibs: Link Options. (line 79)
-* unresolved references and -nostdlib: Link Options. (line 79)
-* unused attribute.: Function Attributes.
- (line 1167)
-* UR fixed-suffix: Fixed-Point. (line 6)
-* ur fixed-suffix: Fixed-Point. (line 6)
-* used attribute.: Function Attributes.
- (line 1172)
-* User stack pointer in interrupts on the Blackfin: Function Attributes.
- (line 576)
-* 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 66)
-* variable addressability on the IA-64: Function Attributes.
- (line 643)
-* variable addressability on the M32R/D: Variable Attributes.
- (line 330)
-* variable alignment: Alignment. (line 6)
-* variable attributes: Variable Attributes.
- (line 6)
-* variable number of arguments: Variadic Macros. (line 6)
-* variable-length array scope: Variable Length. (line 23)
-* variable-length arrays: Variable Length. (line 6)
-* variables in specified registers: Explicit Reg Vars. (line 6)
-* variables, local, in macros: Typeof. (line 42)
-* variadic macros: Variadic Macros. (line 6)
-* VAX options: VAX Options. (line 6)
-* version_id attribute: Function Attributes.
- (line 1178)
-* vfprintf: Other Builtins. (line 6)
-* vfscanf: Other Builtins. (line 6)
-* visibility attribute: Function Attributes.
- (line 1188)
-* VLAs: Variable Length. (line 6)
-* void pointers, arithmetic: Pointer Arith. (line 6)
-* void, size of pointer to: Pointer Arith. (line 6)
-* volatile access: Volatiles. (line 6)
-* volatile applied to function: Function Attributes.
- (line 6)
-* volatile read: Volatiles. (line 6)
-* volatile write: 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 28)
-* VxWorks Options: VxWorks Options. (line 6)
-* W floating point suffix: Floating Types. (line 6)
-* w floating point suffix: Floating Types. (line 6)
-* warn_unused_result attribute: Function Attributes.
- (line 1282)
-* warning for comparison of signed and unsigned values: Warning Options.
- (line 940)
-* warning for overloaded virtual fn: C++ Dialect Options.
- (line 464)
-* warning for reordering of member initializers: C++ Dialect Options.
- (line 389)
-* warning for unknown pragmas: Warning Options. (line 587)
-* warning function attribute: Function Attributes.
- (line 158)
-* warning messages: Warning Options. (line 6)
-* warnings from system headers: Warning Options. (line 701)
-* warnings vs errors: Warnings and Errors.
- (line 6)
-* weak attribute: Function Attributes.
- (line 1299)
-* weakref attribute: Function Attributes.
- (line 1308)
-* whitespace: Incompatibilities. (line 112)
-* X in constraint: Simple Constraints. (line 114)
-* X3.159-1989: Standards. (line 13)
-* x86-64 options: x86-64 Options. (line 6)
-* x86-64 Options: i386 and 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)
-
-
-\1f
-Tag Table:
-Node: Top\7f2062
-Node: G++ and GCC\7f3759
-Node: Standards\7f5824
-Node: Invoking GCC\7f14799
-Node: Option Summary\7f18628
-Node: Overall Options\7f51271
-Node: Invoking G++\7f65106
-Node: C Dialect Options\7f66629
-Node: C++ Dialect Options\7f80520
-Node: Objective-C and Objective-C++ Dialect Options\7f102114
-Node: Language Independent Options\7f113895
-Node: Warning Options\7f116665
-Node: Debugging Options\7f175012
-Node: Optimize Options\7f213831
-Ref: Type-punning\7f260632
-Node: Preprocessor Options\7f317043
-Ref: Wtrigraphs\7f321141
-Ref: dashMF\7f325889
-Ref: fdollars-in-identifiers\7f336408
-Node: Assembler Options\7f344969
-Node: Link Options\7f345674
-Ref: Link Options-Footnote-1\7f355144
-Node: Directory Options\7f355478
-Node: Spec Files\7f361540
-Node: Target Options\7f381879
-Node: Submodel Options\7f383397
-Node: ARC Options\7f385096
-Node: ARM Options\7f386583
-Node: AVR Options\7f398817
-Node: Blackfin Options\7f400906
-Node: CRIS Options\7f408798
-Node: CRX Options\7f412539
-Node: Darwin Options\7f412964
-Node: DEC Alpha Options\7f420457
-Node: DEC Alpha/VMS Options\7f432373
-Node: FR30 Options\7f432759
-Node: FRV Options\7f433334
-Node: GNU/Linux Options\7f440051
-Node: H8/300 Options\7f440509
-Node: HPPA Options\7f441576
-Node: i386 and x86-64 Options\7f451076
-Node: IA-64 Options\7f479061
-Node: M32C Options\7f486386
-Node: M32R/D Options\7f487677
-Node: M680x0 Options\7f491264
-Node: M68hc1x Options\7f505084
-Node: MCore Options\7f506652
-Node: MIPS Options\7f508160
-Node: MMIX Options\7f534195
-Node: MN10300 Options\7f536677
-Node: PDP-11 Options\7f538099
-Node: picoChip Options\7f539939
-Node: PowerPC Options\7f542138
-Node: RS/6000 and PowerPC Options\7f542374
-Node: S/390 and zSeries Options\7f573121
-Node: Score Options\7f581069
-Node: SH Options\7f581897
-Node: SPARC Options\7f592175
-Node: SPU Options\7f603148
-Node: System V Options\7f606436
-Node: V850 Options\7f607259
-Node: VAX Options\7f610399
-Node: VxWorks Options\7f610947
-Node: x86-64 Options\7f612102
-Node: i386 and x86-64 Windows Options\7f612320
-Node: Xstormy16 Options\7f614639
-Node: Xtensa Options\7f614928
-Node: zSeries Options\7f619075
-Node: Code Gen Options\7f619271
-Node: Environment Variables\7f643850
-Node: Precompiled Headers\7f651746
-Node: Running Protoize\7f657972
-Node: C Implementation\7f664309
-Node: Translation implementation\7f665972
-Node: Environment implementation\7f666546
-Node: Identifiers implementation\7f667096
-Node: Characters implementation\7f668150
-Node: Integers implementation\7f670956
-Node: Floating point implementation\7f672781
-Node: Arrays and pointers implementation\7f675710
-Ref: Arrays and pointers implementation-Footnote-1\7f677145
-Node: Hints implementation\7f677269
-Node: Structures unions enumerations and bit-fields implementation\7f678735
-Node: Qualifiers implementation\7f680721
-Node: Declarators implementation\7f682493
-Node: Statements implementation\7f682835
-Node: Preprocessing directives implementation\7f683162
-Node: Library functions implementation\7f685267
-Node: Architecture implementation\7f685907
-Node: Locale-specific behavior implementation\7f686610
-Node: C Extensions\7f686915
-Node: Statement Exprs\7f691526
-Node: Local Labels\7f696039
-Node: Labels as Values\7f699018
-Ref: Labels as Values-Footnote-1\7f701391
-Node: Nested Functions\7f701574
-Node: Constructing Calls\7f705468
-Node: Typeof\7f710191
-Node: Conditionals\7f713357
-Node: Long Long\7f714248
-Node: Complex\7f715749
-Node: Floating Types\7f718319
-Node: Decimal Float\7f719398
-Node: Hex Floats\7f721387
-Node: Fixed-Point\7f722428
-Node: Zero Length\7f725713
-Node: Empty Structures\7f728991
-Node: Variable Length\7f729407
-Node: Variadic Macros\7f732174
-Node: Escaped Newlines\7f734556
-Node: Subscripting\7f735395
-Node: Pointer Arith\7f736118
-Node: Initializers\7f736686
-Node: Compound Literals\7f737182
-Node: Designated Inits\7f739357
-Node: Case Ranges\7f743012
-Node: Cast to Union\7f743695
-Node: Mixed Declarations\7f744791
-Node: Function Attributes\7f745297
-Node: Attribute Syntax\7f807913
-Node: Function Prototypes\7f818183
-Node: C++ Comments\7f819964
-Node: Dollar Signs\7f820483
-Node: Character Escapes\7f820948
-Node: Alignment\7f821242
-Node: Variable Attributes\7f822616
-Ref: i386 Variable Attributes\7f837206
-Node: Type Attributes\7f843191
-Ref: i386 Type Attributes\7f856812
-Ref: PowerPC Type Attributes\7f857652
-Ref: SPU Type Attributes\7f858514
-Node: Inline\7f858805
-Node: Extended Asm\7f863752
-Ref: Example of asm with clobbered asm reg\7f869838
-Node: Constraints\7f884057
-Node: Simple Constraints\7f884907
-Node: Multi-Alternative\7f891578
-Node: Modifiers\7f893295
-Node: Machine Constraints\7f896189
-Node: Asm Labels\7f928402
-Node: Explicit Reg Vars\7f930078
-Node: Global Reg Vars\7f931686
-Node: Local Reg Vars\7f936236
-Node: Alternate Keywords\7f938677
-Node: Incomplete Enums\7f940105
-Node: Function Names\7f940862
-Node: Return Address\7f943024
-Node: Vector Extensions\7f945821
-Node: Offsetof\7f949323
-Node: Atomic Builtins\7f950137
-Node: Object Size Checking\7f955515
-Node: Other Builtins\7f960943
-Node: Target Builtins\7f985751
-Node: Alpha Built-in Functions\7f986645
-Node: ARM iWMMXt Built-in Functions\7f989644
-Node: ARM NEON Intrinsics\7f996363
-Node: Blackfin Built-in Functions\7f1204201
-Node: FR-V Built-in Functions\7f1204815
-Node: Argument Types\7f1205674
-Node: Directly-mapped Integer Functions\7f1207430
-Node: Directly-mapped Media Functions\7f1208512
-Node: Raw read/write Functions\7f1215544
-Node: Other Built-in Functions\7f1216456
-Node: X86 Built-in Functions\7f1217645
-Node: MIPS DSP Built-in Functions\7f1262085
-Node: MIPS Paired-Single Support\7f1274532
-Node: MIPS Loongson Built-in Functions\7f1276033
-Node: Paired-Single Arithmetic\7f1282551
-Node: Paired-Single Built-in Functions\7f1283497
-Node: MIPS-3D Built-in Functions\7f1286167
-Node: picoChip Built-in Functions\7f1291542
-Node: Other MIPS Built-in Functions\7f1292904
-Node: PowerPC AltiVec Built-in Functions\7f1293428
-Node: SPARC VIS Built-in Functions\7f1394852
-Node: SPU Built-in Functions\7f1396544
-Node: Target Format Checks\7f1398326
-Node: Solaris Format Checks\7f1398733
-Node: Pragmas\7f1399130
-Node: ARM Pragmas\7f1399824
-Node: M32C Pragmas\7f1400427
-Node: RS/6000 and PowerPC Pragmas\7f1401003
-Node: Darwin Pragmas\7f1401745
-Node: Solaris Pragmas\7f1402812
-Node: Symbol-Renaming Pragmas\7f1403973
-Node: Structure-Packing Pragmas\7f1406595
-Node: Weak Pragmas\7f1408247
-Node: Diagnostic Pragmas\7f1409049
-Node: Visibility Pragmas\7f1411683
-Node: Push/Pop Macro Pragmas\7f1412435
-Node: Function Specific Option Pragmas\7f1413408
-Node: Unnamed Fields\7f1415623
-Node: Thread-Local\7f1417133
-Node: C99 Thread-Local Edits\7f1419242
-Node: C++98 Thread-Local Edits\7f1421254
-Node: Binary constants\7f1424699
-Node: C++ Extensions\7f1425370
-Node: Volatiles\7f1427012
-Node: Restricted Pointers\7f1429688
-Node: Vague Linkage\7f1431282
-Node: C++ Interface\7f1434938
-Ref: C++ Interface-Footnote-1\7f1439235
-Node: Template Instantiation\7f1439372
-Node: Bound member functions\7f1446384
-Node: C++ Attributes\7f1447927
-Node: Namespace Association\7f1449585
-Node: Type Traits\7f1450999
-Node: Java Exceptions\7f1456546
-Node: Deprecated Features\7f1457943
-Node: Backwards Compatibility\7f1460908
-Node: Objective-C\7f1462266
-Node: Executing code before main\7f1462847
-Node: What you can and what you cannot do in +load\7f1465453
-Node: Type encoding\7f1467620
-Node: Garbage Collection\7f1471007
-Node: Constant string objects\7f1473631
-Node: compatibility_alias\7f1476139
-Node: Compatibility\7f1477017
-Node: Gcov\7f1483584
-Node: Gcov Intro\7f1484115
-Node: Invoking Gcov\7f1486831
-Node: Gcov and Optimization\7f1498692
-Node: Gcov Data Files\7f1501345
-Node: Cross-profiling\7f1502483
-Node: Trouble\7f1504309
-Node: Actual Bugs\7f1505865
-Node: Cross-Compiler Problems\7f1506605
-Node: Interoperation\7f1507019
-Node: Incompatibilities\7f1514156
-Node: Fixed Headers\7f1522306
-Node: Standard Libraries\7f1523969
-Node: Disappointments\7f1525341
-Node: C++ Misunderstandings\7f1529699
-Node: Static Definitions\7f1530518
-Node: Name lookup\7f1531571
-Ref: Name lookup-Footnote-1\7f1536349
-Node: Temporaries\7f1536536
-Node: Copy Assignment\7f1538512
-Node: Protoize Caveats\7f1540319
-Node: Non-bugs\7f1544292
-Node: Warnings and Errors\7f1554796
-Node: Bugs\7f1556560
-Node: Bug Criteria\7f1557124
-Node: Bug Reporting\7f1559334
-Node: Service\7f1559555
-Node: Contributing\7f1560374
-Node: Funding\7f1561114
-Node: GNU Project\7f1563603
-Node: Copying\7f1564249
-Node: GNU Free Documentation License\7f1601777
-Node: Contributors\7f1624183
-Node: Option Index\7f1660510
-Node: Keyword Index\7f1819678
-\1f
-End Tag Table
+++ /dev/null
-This is doc/gccinstall.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/install.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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
-
-\1f
-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.
-
-\1f
-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/.
-
- 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.
-
-\1f
-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 C90 compiler
- Necessary to bootstrap GCC, although 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 2.95 or later) because source code
- for language frontends other than C might use GCC extensions.
-
-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.
-
-GNU Multiple Precision Library (GMP) version 4.1 (or later)
- Necessary to build GCC. If you do not have it installed 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'. Alternatively, if a GMP source distribution
- is found in a subdirectory of your GCC sources named `gmp', it
- will be built together with GCC.
-
-MPFR Library version 2.3.2 (or later)
- Necessary to build GCC. It can be downloaded from
- `http://www.mpfr.org/'. The version of MPFR that is bundled with
- GMP 4.1.x contains numerous bugs. Although GCC may appear to
- function with the buggy versions of MPFR, there are a few bugs
- that will not be fixed when using this version. It is strongly
- recommended to upgrade to the recommended version of MPFR.
-
- The `--with-mpfr' configure option should be used if your MPFR
- Library is not installed in your default library search path. See
- also `--with-mpfr-lib' and `--with-mpfr-include'. Alternatively,
- if a MPFR source distribution is found in a subdirectory of your
- GCC sources named `mpfr', it will be built together with GCC.
-
-Parma Polyhedra Library (PPL) version 0.10
- Necessary to build GCC with the Graphite loop optimizations. It
- can be downloaded from `http://www.cs.unipr.it/ppl/Download/'.
-
- The `--with-ppl' configure option should be used if PPL is not
- installed in your default library search path.
-
-CLooG-PPL version 0.15
- Necessary to build GCC with the Graphite loop optimizations. It
- can be downloaded from `ftp://gcc.gnu.org/pub/gcc/infrastructure/'.
- The code in `cloog-ppl-0.15.tar.gz' comes from a branch of CLooG
- available from `http://repo.or.cz/w/cloog-ppl.git'. CLooG-PPL
- should be configured with `--with-ppl'.
-
- The `--with-cloog' configure option should be used if CLooG is not
- installed in your default library search path.
-
-`jar', or InfoZIP (`zip' and `unzip')
- Necessary to build libgcj, the GCJ runtime.
-
-
-Tools/packages necessary for modifying GCC
-==========================================
-
-autoconf version 2.59
-GNU m4 version 1.4 (or later)
- Necessary when modifying `configure.ac', `aclocal.m4', etc. to
- regenerate `configure' and `config.in' files.
-
-automake version 1.9.6
- 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.9.x series, which is currently 1.9.6. When regenerating
- a directory to a newer version, please update all the directories
- using an older 1.9.x 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.
-
-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.
-
-Perl version 5.6.1 (or later)
- Necessary when regenerating `Makefile' dependencies in libiberty.
- Necessary when regenerating `libiberty/functions.texi'. Necessary
- when generating manpages from Texinfo manuals. Necessary when
- targetting Darwin, building libstdc++, and not using
- `--disable-symvers'. Used by various scripts to generate some
- files included in SVN (mainly Unicode-related and rarely changing)
- from source tables.
-
-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 a `antlr.jar' library available. The library is searched
- in system locations but can be configured 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.
-
-
-\1f
-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'. It is possible to download a full distribution or specific
-components.
-
- Please refer to the releases web page for information on how to
-obtain GCC.
-
- The full distribution includes the C, C++, Objective-C, Fortran,
-Java, and Ada (in the case of GCC 3.1 and later) compilers. The full
-distribution also includes runtime libraries for C++, Objective-C,
-Fortran, and Java. In GCC 3.0 and later versions, the GNU compiler
-testsuites are also included in the full distribution.
-
- If you choose to download specific components, you must download the
-core GCC distribution plus any language specific distributions you wish
-to use. The core distribution includes the C language front end as
-well as the shared components. Each language has a tarball which
-includes the language front end as well as the language runtime (when
-appropriate).
-
- Unpack the core distribution as well as any language specific
-distributions in the same directory.
-
- 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 and MPFR libraries can be automatically built
-together with GCC. Unpack the GMP and/or MPFR source distributions in
-the directory containing the GCC sources and rename their directories to
-`gmp' and `mpfr', respectively (or use symbolic links with the same
-name).
-
-\1f
-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' 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 than 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
- 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-coff,
- 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'.
-
- `--infodir=DIRNAME'
- Specify the installation directory for documentation in info
- format. The default is `PREFIX/info'.
-
- `--datadir=DIRNAME'
- Specify the installation directory for some
- architecture-independent data files referenced by GCC. The
- default is `PREFIX/share'.
-
- `--mandir=DIRNAME'
- Specify the installation directory for manual pages. The
- default is `PREFIX/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 is `PREFIX/include/c++/VERSION'.
-
-
-`--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.
-
-`--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' 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.
-
-`--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.
-
-`--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'):
- `arc-*-elf*'
- biendian.
-
- `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.
-
-
-`--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.
-
- `gnat'
- Ada tasking support. For non-Ada programs, this setting is
- equivalent to `single'. When used in conjunction with the
- Ada run time, it causes GCC to use the same thread primitives
- as Ada uses. This option is necessary when using both Ada
- and the back end exception handling, which is the default for
- most Ada targets.
-
- `mach'
- Generic MACH thread support, known to work on NeXTSTEP.
- (Please note that the file needed to support this
- configuration, `gthr-mach.h', is missing and thus this
- setting will cause a known bootstrap failure.)
-
- `no'
- This is an alias for `single'.
-
- `posix'
- Generic POSIX/Unix98 thread support.
-
- `posix95'
- Generic POSIX/Unix95 thread support.
-
- `rtems'
- RTEMS thread support.
-
- `single'
- Disable thread support, should work for all platforms.
-
- `solaris'
- Sun Solaris 2 thread support.
-
- `vxworks'
- VxWorks thread support.
-
- `win32'
- Microsoft Win32 API thread support.
-
- `nks'
- Novell Kernel Services 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
- ARM, i386, M68k, PowerPC, and SPARC. 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 and
- x86-64.
-
-`--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-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-lsc'
- 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-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-target-optspace'
- Specify that target libraries should be optimized for code space
- instead of code speed. This is the default for the m32r platform.
-
-`--disable-cpp'
- Specify that a user visible `cpp' program should not be installed.
-
-`--with-cpp-install-dir=DIRNAME'
- Specify that the user visible `cpp' program should be installed in
- `PREFIX/DIRNAME/cpp', in addition to BINDIR.
-
-`--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-maintainer-mode'
- The build rules that regenerate 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 could happen
- 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', `libmudflap', `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', `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 and
- Objective-C++ are not default languages; the rest are.
- Re-defining `LANGUAGES' when calling `make' *does not* work
- anymore, as those language sub-directories might not have been
- configured!
-
-`--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-libgomp'
- Specify that the run-time libraries used by GOMP 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. Currently, this option only affects sparc-linux,
- powerpc-linux and x86-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'.
-
-`--with-gc'
-`--with-gc=CHOICE'
- With this option you can specify the garbage collector
- implementation used during the compilation process. CHOICE can be
- one of `page' and `zone', where `page' is the default.
-
-`--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'
- If you do not have GMP (the GNU Multiple Precision library) and the
- MPFR Libraries installed in a standard location and you want to
- build GCC, you can explicitly specify the directory where they are
- installed (`--with-gmp=GMPINSTALLDIR',
- `--with-mpfr=MPFRINSTALLDIR'). 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'. If these shorthand
- assumptions are not correct, you can use the explicit include and
- lib options directly.
-
-`--with-ppl=PATHNAME'
-`--with-ppl-include=PATHNAME'
-`--with-ppl-lib=PATHNAME'
-`--with-cloog=PATHNAME'
-`--with-cloog-include=PATHNAME'
-`--with-cloog-lib=PATHNAME'
- If you do not have PPL (the Parma Polyhedra Library) 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-ppl=PPLINSTALLDIR',
- `--with-cloog=CLOOGINSTALLDIR'). The `--with-ppl=PPLINSTALLDIR'
- option is shorthand for `--with-ppl-lib=PPLINSTALLDIR/lib' and
- `--with-ppl-include=PPLINSTALLDIR/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.
-
-`--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-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'.
-
-
-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 in there. 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.
-
-`--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.
-
-`--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-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 a `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.
-
- `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.
-
-
-\1f
-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_LIBCFLAGS' 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.
-
-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 first recommend 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.79 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 3.4 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.
-
-\1f
-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 `make check-g++' 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
- --target_board=arm-sim/-mhard-float/-O2
- --target_board=arm-sim/-mhard-float/-O3
- --target_board=arm-sim/-mhard-float
- --target_board=arm-sim/-msoft-float/-O1
- --target_board=arm-sim/-msoft-float/-O2
- --target_board=arm-sim/-msoft-float/-O3
- --target_board=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.
-
-\1f
-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.
-
- 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'.
-
-\1f
-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.
-
- * Motorola 68HC11/68HC12--GNU Development Tools for the Motorola
- 68HC11/68HC12.
-
- * SCO OpenServer/Unixware.
-
- * Solaris 2 (SPARC, Intel)--Sunfreeware.
-
- * SGI--SGI Freeware.
-
- * Microsoft Windows:
- * The Cygwin project;
-
- * The MinGW project.
-
- * The Written Word offers binaries for AIX 4.3.3, 5.1 and 5.2, IRIX
- 6.5, Tru64 UNIX 4.0D and 5.1, 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.
-
- In addition to those specific offerings, you can get a binary
-distribution CD-ROM from the Free Software Foundation. It contains
-binaries for a number of platforms, and includes not only GCC, but
-other stuff as well. The current CD does not contain the latest
-version of GCC, but it should allow bootstrapping the compiler. An
-updated version of that disk is in the works.
-
-\1f
-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
-are.
-
-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-osf*
-===============
-
-Systems using processors that implement the DEC Alpha architecture and
-are running the DEC/Compaq Unix (DEC OSF/1, Digital UNIX, or Compaq
-Tru64 UNIX) operating system, for example the DEC Alpha AXP systems.
-
- 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.)
-
- In Digital Unix V4.0, virtual memory exhausted bootstrap failures
-may be fixed by configuring with `--with-gc=simple', reconfiguring
-Kernel Virtual Memory and Swap parameters per the `/usr/sbin/sys_check'
-Tuning Suggestions, or applying the patch in
-`http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html'.
-
- In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not
-currently (2001-06-13) work with `mips-tfile'. As a workaround, we
-need to use the old assembler, invoked via the barely documented
-`-oldas' option. To bootstrap GCC, you either need to use the Compaq C
-Compiler:
-
- % CC=cc SRCDIR/configure [OPTIONS] [TARGET]
-
- or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX
-V4.0:
-
- % CC=gcc -Wa,-oldas SRCDIR/configure [OPTIONS] [TARGET]
-
- As of GNU binutils 2.11.2, neither GNU `as' nor GNU `ld' are
-supported on Tru64 UNIX, so you must not configure GCC with
-`--with-gnu-as' or `--with-gnu-ld'.
-
- GCC writes a `.verstamp' directive to the assembler output file
-unless it is built as a cross-compiler. It gets the version to use from
-the system header file `/usr/include/stamp.h'. If you install a new
-version of DEC Unix, you should rebuild GCC to pick up the new version
-stamp.
-
- `make compare' may fail on old versions of DEC Unix unless you add
-`-save-temps' to `BOOT_CFLAGS'. On these systems, the name of the
-assembler input file is stored in the object file, and that makes
-comparison fail if it differs between the `stage1' and `stage2'
-compilations. The option `-save-temps' forces a fixed name to be used
-for the assembler input file, instead of a randomly chosen name in
-`/tmp'. Do not add `-save-temps' unless the comparisons fail without
-that option. If you add `-save-temps', you will have to manually
-delete the `.i' and `.s' files after each series of compilations.
-
- GCC now supports both the native (ECOFF) debugging format used by DBX
-and GDB and an encapsulated STABS format for use only with GDB. See the
-discussion of the `--with-stabs' option of `configure' above for more
-information on these formats and how to select them.
-
- There is a bug in DEC's assembler that produces incorrect line
-numbers for ECOFF format when the `.align' directive is used. To work
-around this problem, GCC will not emit such alignment directives while
-writing ECOFF format debugging information even if optimization is
-being performed. Unfortunately, this has the very undesirable
-side-effect that code addresses when `-O' is specified are different
-depending on whether or not `-g' is also specified.
-
- To avoid this behavior, specify `-gstabs+' and use GDB instead of
-DBX. DEC is now aware of this problem with the assembler and hopes to
-provide a fix shortly.
-
-arc-*-elf
-=========
-
-Argonaut ARC processor. This configuration is intended for embedded
-systems.
-
-arm-*-elf
-=========
-
-ARM-family processors. Subtargets that use the ELF object format
-require GNU binutils 2.13 or newer. Such subtargets include:
-`arm-*-freebsd', `arm-*-netbsdelf', `arm-*-*linux' and `arm-*-rtems'.
-
-arm-*-coff
-==========
-
-ARM-family processors. Note that there are two different varieties of
-PE format subtarget supported: `arm-wince-pe' and `arm-pe' as well as a
-standard COFF target `arm-*-coff'.
-
-arm-*-aout
-==========
-
-ARM-family processors. These targets support the AOUT file format:
-`arm-*-aout', `arm-*-netbsd'.
-
-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'
-
-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/'.
-
-CRX
-===
-
-The CRX CompactRISC architecture is a low-power 32-bit architecture with
-fast context switching and architectural extensibility features.
-
- *Note CRX Options: (gcc)CRX Options,
-
- Use `configure --target=crx-elf --enable-languages=c,c++' to
-configure GCC for building a CRX cross-compiler. The option
-`--target=crx-elf' is also used to build the `newlib' C library for CRX.
-
- It is also possible to build libstdc++-v3 for the CRX architecture.
-This needs to be done in a separate step with the following configure
-settings: `gcc/libstdc++-v3/configure --host=crx-elf --with-newlib
---enable-sjlj-exceptions --enable-cxx-flags='-fexceptions -frtti''
-
-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.
-
-*-*-freebsd*
-============
-
-The version of binutils installed in `/usr/bin' probably works with
-this release of GCC. However, on FreeBSD 4, bootstrapping against the
-latest FSF binutils is known to improve overall testsuite results; and,
-on FreeBSD/alpha, using binutils 2.14 or later is required to build
-libjava.
-
- Support for FreeBSD 1 was discontinued in GCC 3.2.
-
- Support for FreeBSD 2 will be discontinued after GCC 3.4. The
-following was true for GCC 3.1 but the current status is unknown. For
-FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All configuration
-support and files as shipped with GCC 2.95 are still in place. FreeBSD
-2.2.7 has been known to bootstrap completely; however, it is unknown
-which version of binutils was used (it is assumed that it was the
-system copy in `/usr/bin') and C++ EH failures were noted.
-
- For FreeBSD using the ELF file format: DWARF 2 debugging is now the
-default for all CPU architectures. It had been the default on
-FreeBSD/alpha since its inception. 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 4.9-STABLE and 5-CURRENT. 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-STABLE.
-
- In principle, `--enable-threads' is now compatible with
-`--enable-libgcj' on FreeBSD. However, it has only been built and
-tested on `i386-*-freebsd[45]' and `alpha-*-freebsd[45]'. The static
-library may be incorrectly built (symbols are missing at link time).
-There is a rare timing-based startup hang (probably involves an
-assumption about the thread library). Multi-threaded boehm-gc
-(required for libjava) exposes severe threaded signal-handling bugs on
-FreeBSD before 4.5-RELEASE. Other CPU architectures supported by
-FreeBSD will require additional configuration tuning in, at the very
-least, both boehm-gc and libffi.
-
- Shared `libgcc_s.so' is now built and installed by default.
-
-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. HP has two sites which provide patches free of
-charge:
-
- * `http://us.itrc.hp.com/service/home/home.do' US, Canada,
- Asia-Pacific, and Latin-America.
-
- * `http://europe.itrc.hp.com/service/home/home.do' Europe.
-
- 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.10
-==================
-
-Use this for Solaris 10 or later on x86 and x86-64 systems. This
-configuration is supported by GCC 4.0 and later versions only.
-
- It is recommended that you configure GCC to use the GNU assembler in
-`/usr/sfw/bin/gas' but the Sun linker, using the options `--with-gnu-as
---with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/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.
-
-*-ibm-aix*
-==========
-
-Support for AIX version 3 and older was discontinued in GCC 3.4.
-
- "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.
-
- 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 4
-and required for bootstrapping on AIX 5L. The GNU Assembler reports
-that it supports WEAK symbols on AIX 4, which causes GCC to try to
-utilize weak symbol functionality although it is not supported. The GNU
-Assembler and Linker do not support AIX 5L sufficiently to bootstrap
-GCC. The native AIX tools do interoperate with GCC.
-
- 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 a 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'.
-
- By default, GCC for AIX 4.1 and above produces code that can be used
-on both Power or PowerPC processors.
-
- 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.
-
-m32c-*-elf
-==========
-
-Renesas M32C processor. This configuration is intended for embedded
-systems.
-
-m32r-*-elf
-==========
-
-Renesas M32R processor. This configuration is intended for embedded
-systems.
-
-m6811-elf
-=========
-
-Motorola 68HC11 family micro controllers. These are used in embedded
-applications. There are no standard Unix configurations.
-
-m6812-elf
-=========
-
-Motorola 68HC12 family micro controllers. These are used in embedded
-applications. There are no standard Unix configurations.
-
-m68k-*-*
-========
-
-By default, `m68k-*-aout', `m68k-*-coff*', `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'.
-
-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. However, you can still use the original ABI by
-configuring for `m68k-uclinuxoldabi' or `m68k-VENDOR-uclinuxoldabi'.
-
-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.
-
- Cross-compilers for the MIPS as target using the MIPS assembler
-currently do not work, because the auxiliary programs `mips-tdump.c'
-and `mips-tfile.c' can't be compiled on anything but a MIPS. It does
-work to cross compile for a MIPS if you use the GNU assembler and
-linker.
-
- 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
-==============
-
-In order to compile GCC on an SGI running IRIX 5, the `compiler_dev.hdr'
-subsystem must be installed from the IDO CD-ROM supplied by SGI. It is
-also available for download from
-`ftp://ftp.sgi.com/sgi/IRIX5.3/iris-development-option-5.3.tardist'.
-
- If you use the MIPS C compiler to bootstrap, it may be necessary to
-increase its table size for switch statements with the `-Wf,-XNg1500'
-option. If you use the `-O2' optimization option, you also need to use
-`-Olimit 3000'.
-
- To enable debugging under IRIX 5, you must use GNU binutils 2.15 or
-later, and use the `--with-gnu-ld' `configure' option when configuring
-GCC. You need to use GNU `ar' and `nm', also distributed with GNU
-binutils.
-
- Some users have reported that `/bin/sh' will hang during bootstrap.
-This problem can be avoided by running the commands:
-
- % CONFIG_SHELL=/bin/ksh
- % export CONFIG_SHELL
-
- before starting the build.
-
-mips-sgi-irix6
-==============
-
-If you are using SGI's MIPSpro `cc' as your bootstrap compiler, you must
-ensure that the N32 ABI is in use. To test this, compile a simple C
-file with `cc' and then run `file' on the resulting object file. The
-output should look like:
-
- test.o: ELF N32 MSB ...
-
- If you see:
-
- test.o: ELF 32-bit MSB ...
-
- or
-
- test.o: ELF 64-bit MSB ...
-
- then your version of `cc' uses the O32 or N64 ABI by default. You
-should set the environment variable `CC' to `cc -n32' before
-configuring GCC.
-
- If you want the resulting `gcc' to run on old 32-bit systems with
-the MIPS R4400 CPU, you need to ensure that only code for the `mips3'
-instruction set architecture (ISA) is generated. While GCC 3.x does
-this correctly, both GCC 2.95 and SGI's MIPSpro `cc' may change the ISA
-depending on the machine where GCC is built. Using one of them as the
-bootstrap compiler may result in `mips4' code, which won't run at all
-on `mips3'-only systems. For the test program above, you should see:
-
- test.o: ELF N32 MSB mips-3 ...
-
- If you get:
-
- test.o: ELF N32 MSB mips-4 ...
-
- instead, you should set the environment variable `CC' to `cc -n32
--mips3' or `gcc -mips3' respectively before configuring GCC.
-
- MIPSpro C 7.4 may cause bootstrap failures, due to a bug when
-inlining `memcmp'. Either add `-U__INLINE_INTRINSICS' to the `CC'
-environment variable as a workaround or upgrade to MIPSpro C 7.4.1m.
-
- GCC on IRIX 6 is usually built to support the N32, O32 and N64 ABIs.
-If you build GCC on a system that doesn't have the N64 libraries
-installed or cannot run 64-bit binaries, you need to configure with
-`--disable-multilib' so GCC doesn't try to use them. This will disable
-building the O32 libraries, too. Look for `/usr/lib64/libc.so.1' to
-see if you have the 64-bit libraries installed.
-
- To enable debugging for the O32 ABI, you must use GNU `as' from GNU
-binutils 2.15 or later. You may also use GNU `ld', but this is not
-required and currently causes some problems with Ada.
-
- The `--enable-libgcj' option is disabled by default: IRIX 6 uses a
-very low default limit (20480) for the command line length. Although
-`libtool' contains a workaround for this problem, at least the N64
-`libgcj' is known not to build despite this, running into an internal
-error of the native `ld'. A sure fix is to increase this limit
-(`ncargs') to its maximum of 262144 bytes. If you have root access,
-you can use the `systune' command to do this.
-
- `wchar_t' support in `libstdc++' is not available for old IRIX 6.5.x
-releases, x < 19. The problem cannot be autodetected and in order to
-build GCC for such targets you need to configure with
-`--disable-wchar_t'.
-
- See `http://freeware.sgi.com/' for more information about using GCC
-on IRIX platforms.
-
-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://developer.apple.com/darwin/projects/compiler/' (free
-registration required).
-
- 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.
-
-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*
-=============
-
-Sun does not ship a C compiler with Solaris 2. To bootstrap and install
-GCC you first have to install a pre-built compiler, 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 GNU binutils 2.14 or later, or the vendor
-tools (Sun `as', Sun `ld'). 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' is known to cause memory corruption at runtime in some
-cases for C++ programs.
-
- The stock GNU binutils 2.15 release is broken on this platform
-because of a single bug. It has been fixed on the 2.15 branch in the
-CVS repository. You can obtain a working version by checking out the
-binutils-2_15-branch from the CVS repository or applying the patch
-`http://sourceware.org/ml/binutils-cvs/2004-09/msg00036.html' to the
-release.
-
- We recommend the use of GNU binutils 2.16 or later in conjunction
-with GCC 4.x, or the vendor tools (Sun `as', Sun `ld'). However, for
-Solaris 10 and above, an additional patch is required in order for the
-GNU linker to be able to cope with a new flavor of shared libraries.
-You can obtain a working version by checking out the
-binutils-2_16-branch from the CVS repository or applying the patch
-`http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html' to the
-release.
-
- 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
-C89 but is wrong for C++, and is now wrong for C99 also.
-
- `g++' accepts such (invalid) constructs with the option
-`-fpermissive'; it will assume that any missing type is `int' (as
-defined by C89).
-
- There are patches for Solaris 7 (108376-21 or newer for SPARC,
-108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC,
-108653-22 for Intel) that fix this bug.
-
- 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 8 (117350-12 or newer for SPARC,
-117351-12 or newer for Intel) and Solaris 9 (117171-11 or newer for
-SPARC, 117172-11 or newer for Intel) that address this problem.
-
-sparc-sun-solaris2*
-===================
-
-When GCC is configured to use 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 a 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) or the MPFR
-library on a Solaris 7 or later system, the canonical target triplet
-must be specified as the `build' parameter on the configure line. This
-triplet can be obtained by invoking ./config.guess in the toplevel
-source directory of GCC (and not that of GMP or MPFR). For example on
-a Solaris 7 system:
-
- % ./configure --build=sparc-sun-solaris2.7 --prefix=xxx
-
-sparc-sun-solaris2.7
-====================
-
-Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
-the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and
-later, including all EGCS releases. Sun formerly recommended 107058-01
-for all Solaris 7 users, but around 1999-09-01 it started to recommend
-it only for people who use Sun's compilers.
-
- Here are some workarounds to this problem:
- * Do not install Sun patch 107058-01 until after Sun releases a
- complete patch for bug 4210064. This is the simplest course to
- take, unless you must also use Sun's C compiler. Unfortunately
- 107058-01 is preinstalled on some new Solaris 7-based hosts, so
- you may have to back it out.
-
- * Copy the original, unpatched Solaris 7 `/usr/ccs/bin/as' into
- `/usr/local/libexec/gcc/sparc-sun-solaris2.7/3.4/as', adjusting
- the latter name to fit your local conventions and software version
- numbers.
-
- * Install Sun patch 106950-03 (1999-05-25) or later. Nobody with
- both 107058-01 and 106950-03 installed has reported the bug with
- GCC and Sun's dynamic linker. This last course of action is
- riskiest, for two reasons. First, you must install 106950 on all
- hosts that run code generated by GCC; it doesn't suffice to
- install it only on the hosts that run GCC itself. Second, Sun
- says that 106950-03 is only a partial fix for bug 4210064, but Sun
- doesn't know whether the partial fix is adequate for GCC.
- Revision -08 or later should fix the bug. The current (as of
- 2004-05-23) revision is -24, and is included in the Solaris 7
- Recommended Patch Cluster.
-
- GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun
-assembler, which causes a bootstrap failure when linking the 64-bit
-shared version of libgcc. A typical error message is:
-
- ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o:
- symbol <unknown>: offset 0xffffffff7ec133e7 is non-aligned.
-
- This bug has been fixed in the final 5.0 version of the assembler.
-
- A similar problem was reported for version Sun WorkShop 6 99/08/18
-of the Sun assembler, which causes a bootstrap failure with GCC 4.0.0:
-
- ld: fatal: relocation error: R_SPARC_DISP32:
- file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
- symbol <unknown>: offset 0xfccd33ad is non-aligned
-
- This bug has been fixed in more recent revisions of the assembler.
-
-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) or the MPFR
-library, the canonical target triplet must be specified as the `build'
-parameter on the configure line. For example on a Solaris 7 system:
-
- % ./configure --build=sparc64-sun-solaris2.7 --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*.
-
-*-*-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).
-
-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 *-*-mingw: 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 ARM (arm-wince-pe), 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.
-
- Cygwin can be compiled with i?86-pc-cygwin.
-
-*-*-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.
-
- For more information, see `http://www.interix.com/'.
-
-*-*-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.
-
-OS/2
-====
-
-GCC does not currently support OS/2. However, Andrew Zabolotny has been
-working on a generic OS/2 port with pgcc. The current code can be found
-at http://www.goof.com/pcg/os2/.
-
-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.
-
-\1f
-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.
-
-
-\1f
-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, m6811, m6812, 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. If you want to install your own homemade configuration files,
-you can use `local' as the company name to access them. If you use
-configuration `CPU-local', the configuration name without the cpu prefix
-is used to form the configuration file names.
-
- Thus, if you specify `m68k-local', configuration uses files
-`m68k.md', `local.h', `m68k.c', `xm-local.h', `t-local', and `x-local',
-all in the directory `config/m68k'.
-
-\1f
-File: gccinstall.info, Node: GNU Free Documentation License, Next: Concept Index, Prev: Old, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-File: gccinstall.info, Node: Concept Index, Prev: GNU Free Documentation License, Up: Top
-
-Concept Index
-*************
-
-\0\b[index\0\b]
-* Menu:
-
-* Binaries: Binaries. (line 6)
-* 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)
-* 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)
-* Testing: Testing. (line 6)
-* Testsuite: Testing. (line 6)
-
-
-\1f
-Tag Table:
-Node: Top\7f1939
-Node: Installing GCC\7f2497
-Node: Prerequisites\7f4012
-Node: Downloading the source\7f13017
-Node: Configuration\7f14938
-Ref: with-gnu-as\7f28355
-Ref: with-as\7f29253
-Ref: with-gnu-ld\7f30666
-Node: Building\7f67823
-Node: Testing\7f79766
-Node: Final install\7f87546
-Node: Binaries\7f92776
-Node: Specific\7f94749
-Ref: alpha-x-x\7f95255
-Ref: alpha-dec-osf\7f95744
-Ref: arc-x-elf\7f98867
-Ref: arm-x-elf\7f98967
-Ref: arm-x-coff\7f99187
-Ref: arm-x-aout\7f99389
-Ref: avr\7f99511
-Ref: bfin\7f100153
-Ref: cris\7f100395
-Ref: crx\7f101211
-Ref: dos\7f101874
-Ref: x-x-freebsd\7f102197
-Ref: h8300-hms\7f104580
-Ref: hppa-hp-hpux\7f104932
-Ref: hppa-hp-hpux10\7f107303
-Ref: hppa-hp-hpux11\7f107936
-Ref: x-x-linux-gnu\7f113595
-Ref: ix86-x-linux\7f113788
-Ref: ix86-x-solaris210\7f114101
-Ref: ia64-x-linux\7f114487
-Ref: ia64-x-hpux\7f115257
-Ref: x-ibm-aix\7f115812
-Ref: iq2000-x-elf\7f121795
-Ref: m32c-x-elf\7f121935
-Ref: m32r-x-elf\7f122037
-Ref: m6811-elf\7f122139
-Ref: m6812-elf\7f122289
-Ref: m68k-x-x\7f122439
-Ref: m68k-x-uclinux\7f123444
-Ref: mips-x-x\7f123807
-Ref: mips-sgi-irix5\7f126484
-Ref: mips-sgi-irix6\7f127432
-Ref: powerpc-x-x\7f130239
-Ref: powerpc-x-darwin\7f130444
-Ref: powerpc-x-elf\7f130991
-Ref: powerpc-x-linux-gnu\7f131076
-Ref: powerpc-x-netbsd\7f131171
-Ref: powerpc-x-eabisim\7f131259
-Ref: powerpc-x-eabi\7f131385
-Ref: powerpcle-x-elf\7f131461
-Ref: powerpcle-x-eabisim\7f131553
-Ref: powerpcle-x-eabi\7f131686
-Ref: s390-x-linux\7f131769
-Ref: s390x-x-linux\7f131841
-Ref: s390x-ibm-tpf\7f131928
-Ref: x-x-solaris2\7f132059
-Ref: sparc-sun-solaris2\7f135936
-Ref: sparc-sun-solaris27\7f138657
-Ref: sparc-x-linux\7f141121
-Ref: sparc64-x-solaris2\7f141346
-Ref: sparcv9-x-solaris2\7f141991
-Ref: x-x-vxworks\7f142076
-Ref: x86-64-x-x\7f143598
-Ref: xtensa-x-elf\7f143926
-Ref: xtensa-x-linux\7f144597
-Ref: windows\7f144938
-Ref: x-x-cygwin\7f146893
-Ref: x-x-interix\7f147163
-Ref: x-x-mingw32\7f147529
-Ref: os2\7f147755
-Ref: older\7f147946
-Ref: elf\7f150063
-Node: Old\7f150321
-Node: Configurations\7f153458
-Node: GNU Free Documentation License\7f157440
-Node: Concept Index\7f179856
-\1f
-End Tag Table
+++ /dev/null
-This is doc/gccint.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/gccint.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-
-
-\1f
-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.4.3. 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.
-* Options:: Option specification files.
-* Passes:: Order of passes, what they do, and what each file is for.
-* Trees:: The source representation used by the C and C++ front ends.
-* 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.
-
-* 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.
-
-\1f
-File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, 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/'.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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 Other Builtins: (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::
-
-\1f
-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 __udivmoddi3 (unsigned long A,
- unsigned long B, unsigned long *C)
- -- Runtime Function: unsigned long long __udivti3 (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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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
-
-\1f
-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.
-
-\1f
-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 Trees::), 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.
-
-\1f
-File: gccint.info, Node: Source Tree, Next: Options, 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.
-* Testsuites:: The GCC testsuites.
-
-\1f
-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.
-
-\1f
-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.
-
-`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.
-
-`fastjar'
- An implementation of the `jar' command, used with the Java front
- end.
-
-`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.
-
-`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.
-
-`libcpp'
- The C preprocessor library.
-
-`libgfortran'
- The Fortran runtime library.
-
-`libffi'
- The `libffi' library, used as part of the Java 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.
-
-`libjava'
- The Java runtime library.
-
-`libmudflap'
- The `libmudflap' library, used for instrumenting pointer and array
- dereferencing operations.
-
-`libobjc'
- The Objective-C and Objective-C++ runtime library.
-
-`libstdc++-v3'
- The C++ runtime library.
-
-`maintainer-scripts'
- Scripts used by the `gccadmin' account on `gcc.gnu.org'.
-
-`zlib'
- The `zlib' compression library, used by the Java front end and as
- part of the Java runtime library.
-
- 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.
-
-\1f
-File: gccint.info, Node: gcc Directory, Next: Testsuites, 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.
-
-\1f
-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 `cp' (for C++), `objc' (for Objective-C) and
- `objcp' (for Objective-C++) 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.
-
-`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::.
-
-\1f
-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'.
-
-\1f
-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'.
-
-\1f
-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.
-
-\1f
-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.
-
- * `fixinc/Makefile' is constructed from `fixinc/Makefile.in'.
-
- * `gccbug', a script for reporting bugs in GCC, is constructed from
- `gccbug.in'.
-
- * `intl/Makefile' is constructed from `intl/Makefile.in'.
-
- * 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 `.c' file. FIXME:
- why is such a separate header necessary?
-
-\1f
-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::).
-
-\1f
-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 do not exist in CVS
- but should go into a release tarball. One example is
- `gcc/java/parse.c' which is generated from the CVS source file
- `gcc/java/parse.y'.
-
-`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.
-
-`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)'
- Rebuild all the stages up to N, with the appropriate flags,
- "bubbling" the changes as described above.
-
-`all-stageN (N = 1...4)'
- 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. 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)'
- 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.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-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.
-
-\1f
-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.texi'
-`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'. 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 checked into SVN, 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'.
-
-\1f
-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.
-
-\1f
-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 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'
- The GNU General Public License.
-
-`COPYING.LIB'
- The GNU Lesser General Public License.
-
-`*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', `cp',
-`objc', `testsuite'.
-
-\1f
-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'.
-
- 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 mentioned in
- `gcc/gccbug.in', as well as being 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' (*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. The associated `maintainer-scripts/snapshot-README' and
- `maintainer-scripts/snapshot-index.html' files should be updated
- to list the tarballs and diffs 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.
-
-\1f
-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 build 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. 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.
-
- `srcextra'
- Copies its dependencies into the source directory. This
- generally should be used for generated files such as Bison
- output files which are not present in CVS, 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 checked into CVS, but should
- not delete anything checked into CVS.
-
- `Make-lang.in' must also define a variable `LANG_OBJS' to a list
- of host object files that are used by that language.
-
-`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.
-
-\1f
-File: gccint.info, Node: Front End Config, 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. In
-addition the main directory contains `c-config-lang.in', which contains
-limited information for the C language. 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 stage 1 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::.
-
-
-\1f
-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.
-
-\1f
-File: gccint.info, Node: Testsuites, Prev: gcc Directory, Up: Source Tree
-
-6.4 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.
-* 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.
-
-\1f
-File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites
-
-6.4.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.
-
-\1f
-File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites
-
-6.4.2 Directives used within DejaGnu tests
-------------------------------------------
-
-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 which are usually preceded by
-the keyword `target' or `xfail'. A selector is: one or more target
-triplets, possibly including wildcard characters; a single
-effective-target keyword; or a logical expression. Depending on the
-context, the selector specifies whether a test is skipped and reported
-as unsupported or is expected to fail. Use `*-*-*' to match any target.
-Effective-target keywords are defined in `target-supports.exp' in the
-GCC testsuite.
-
- 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 } }
-
-`{ 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 is included in the
- list of target triplets or matches the effective-target keyword.
-
- 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'.
-
-`{ 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.
-
- The supported values of FEATURE are:
- `c99_runtime'
- The target's C99 runtime (both headers and libraries).
-
- `mips16_attribute'
- `mips16' function attributes. Only MIPS targets support this
- feature, and only then in certain modes.
-
-`{ 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. 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-skip-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
- Skip the test if the test system is included in SELECTOR and if
- each of the options in INCLUDE-OPTS is in the set of options with
- which the test would be compiled and if none of the options in
- EXCLUDE-OPTS is in the set of options with which the test would be
- compiled.
-
- Use `"*"' for an empty INCLUDE-OPTS list and `""' for an empty
- EXCLUDE-OPTS list.
-
-`{ 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') and `dg-xfail-if') are met.
-
-`{ dg-require-SUPPORT args }'
- Skip the test if the target does not provide the required support;
- see `gcc-dg.exp' in the GCC testsuite for the actual directives.
- 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.
-
-`{ dg-require-effective-target KEYWORD }'
- Skip the test if the test target, including current multilib flags,
- is not covered by the effective-target keyword. This directive
- must appear after any `dg-do' directive in the test and before any
- `dg-additional-sources' directive.
-
-`{ 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.
-
-`{ 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-output REGEXP [{ target/xfail SELECTOR }] }'
- This DejaGnu directive compares REGEXP to the combined output that
- the test executable writes to `stdout' and `stderr'.
-
-`{ dg-prune-output REGEXP }'
- Prune messages matching REGEXP from test output.
-
-`{ 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.
-
-`{ 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.
-
- The GCC testsuite defines the following directives to be used
- within `dg-final'.
-
- `cleanup-coverage-files'
- Removes coverage data 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-tree-dump SUFFIX'
- Removes tree dump files matching SUFFIX which were generated
- for this test.
-
- `cleanup-saved-temps'
- Removes files for the current test which were kept for
- `--save-temps'.
-
- `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-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.
-
- `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
- Passes if REGEX is matched exactly NUM times in the test's
- assembler 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-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-tree-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX is found exactly NUM times in the dump file
- with suffix SUFFIX.
-
- `scan-tree-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches text in the dump file with suffix
- SUFFIX.
-
- `scan-tree-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match text in the dump file with
- suffix SUFFIX.
-
- `scan-tree-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches demangled text in the dump file with
- suffix SUFFIX.
-
- `scan-tree-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match demangled text in the dump
- file with suffix SUFFIX.
-
- `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.
-
- `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.
-
-\1f
-File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites
-
-6.4.3 Ada Language Testsuites
------------------------------
-
-The Ada testsuite includes executable tests from the ACATS 2.5
-testsuite, publicly available at
-`http://www.adaic.org/compilers/acats/2.5'
-
- These tests are integrated in the GCC testsuite in the
-`gcc/testsuite/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.
-
- 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'.
-
-\1f
-File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites
-
-6.4.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
- `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.c-torture/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 `bprob.exp', which in
- turn uses the generic, language-independent framework (*note
- Support for testing profile-directed optimizations: profopt
- Testing.).
-
- ``dg-*.c''
- Test the testsuite itself using `dg-test.exp'.
-
- ``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'.
-
-
- FIXME: merge in `testsuite/README.gcc' and discuss the format of test
-cases and magic comments more.
-
-\1f
-File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites
-
-6.4.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.
-
-\1f
-File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites
-
-6.4.6 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 `gcov.exp'. `gcov' tests also rely on procedures in `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.
-
-\1f
-File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites
-
-6.4.7 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
-
-\1f
-File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites
-
-6.4.8 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.
-
-\1f
-File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites
-
-6.4.9 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.
-`gcc/testsuite/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 } ]
-
-\1f
-File: gccint.info, Node: Options, Next: Passes, Prev: Source Tree, Up: Top
-
-7 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
-
-\1f
-File: gccint.info, Node: Option file format, Next: Option properties, Up: Options
-
-7.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.
-
- * 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.
-
-\1f
-File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options
-
-7.2 Option properties
-=====================
-
-The second field of an option record can specify the following
-properties:
-
-`Common'
- The option is available for all languages and targets.
-
-`Target'
- The option is available for all languages but is target-specific.
-
-`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::.
-
-`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
- the option name with the leading "-" removed. This chain action
- will propagate through the `Negative' property of the option to be
- turned off.
-
-`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'.
-
-`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.
-
-`Var(VAR)'
- The state of this option should be stored in variable 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.
-
- * 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 declare VAR in
- `options.c' and leave it to be zero-initialized at start-up time.
- You can modify this behavior using `VarExists' and `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.
-
-`VarExists'
- The variable specified by the `Var' property already exists. No
- definition should be added to `options.c' in response to this
- option record.
-
- You should use this property only if the variable is declared
- outside `options.c'.
-
-`Init(VALUE)'
- The variable specified by the `Var' property should be statically
- initialized to VALUE.
-
-`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 associated
- macros are called `OPTION_MASK_NAME' and `OPTION_NAME'
- respectively.
-
- You can disable automatic bit allocation using `MaskExists'.
-
-`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.
-
-`MaskExists'
- The mask specified by the `Mask' property already exists. No
- `MASK' or `TARGET' definitions should be added to `options.h' in
- response to this option record.
-
- The main purpose of this property is to support synonymous options.
- The first option should use `Mask(NAME)' and the others should use
- `Mask(NAME) MaskExists'.
-
-`Report'
- The state of the option should be printed by `-fverbose-asm'.
-
-`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.
-
-\1f
-File: gccint.info, Node: Passes, Next: Trees, Prev: Options, Up: Top
-
-8 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.
-* 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.
-
-\1f
-File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes
-
-8.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 (CROSSREF), 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 (CROSSREF) on each
-function, and uses the gimplifier callbacks to convert the
-language-specific tree nodes directly to GIMPLE (CROSSREF) 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.
-
-\1f
-File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes
-
-8.2 Gimplification pass
-=======================
-
-"Gimplification" is a whimsical term for the process of converting the
-intermediate representation of a function into the GIMPLE language
-(CROSSREF). 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'.
-
-\1f
-File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes
-
-8.3 Pass manager
-================
-
-The pass manager is located in `passes.c', `tree-optimize.c' and
-`tree-pass.h'. 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 may have its own dump file (for GCC debugging purposes).
-Passes without any names, or with a name starting with a star, do not
-dump anything.
-
- 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...
-
-\1f
-File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes
-
-8.4 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'.
-
- * Mudflap declaration registration
-
- If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize
- Options.) is enabled, we generate code to register some variable
- declarations with the mudflap runtime. Specifically, the runtime
- tracks the lifetimes of those variable declarations that have
- their addresses taken, or whose bounds are unknown at compile time
- (`extern'). This pass generates new exception handling constructs
- (`try'/`finally'), and so must run before those are lowered. In
- addition, the pass enqueues declarations of static variables whose
- lifetimes extend to the entire program. The pass is located in
- `tree-mudflap.c' and is described by `pass_mudflap_1'.
-
- * 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 it
- 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 an 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 and general
- utilities), `tree-vect-analyze.c' and `tree-vect-transform.c'.
- Analysis of data references is in `tree-data-ref.c'.
-
- Autoparallelization. This pass splits the loop iteration space to
- run into several threads. The pass is implemented in
- `tree-parloops.c'.
-
- * 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 patch
- re-introduces COND_EXPR at GIMPLE level. 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'.
-
- * Mudflap statement annotation
-
- If mudflap is enabled, we rewrite some memory accesses with code to
- validate that the memory access is correct. In particular,
- expressions involving pointer dereferences (`INDIRECT_REF',
- `ARRAY_REF', etc.) are replaced by code that checks the selected
- address range against the mudflap runtime's database of valid
- regions. This check includes an inline lookup into a
- direct-mapped cache, based on shift/mask operations of the pointer
- value, with a fallback function call into the runtime. The pass
- is located in `tree-mudflap.c' and is described by
- `pass_mudflap_2'.
-
- * 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'.
-
-
-\1f
-File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes
-
-8.5 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, 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'.
-
- * Register movement
-
- This pass looks for cases where matching constraints would force an
- instruction to need a reload, and this reload would be a
- register-to-register move. It then attempts to change the
- registers used by the instruction to avoid the move instruction.
- The code is located in `regmove.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:
-
- * Register move optimizations. This pass makes some simple RTL
- code transformations which improve the subsequent register
- allocation. The source file is `regmove.c'.
-
- * 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
- pass. Pseudo-registers spilled by the allocator or the
- reload have still a chance to get hard-registers if the
- reload 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.
-
- * 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. If mudflap is enabled, the queue of deferred
- declarations and any addressed constants (e.g., string literals)
- is processed by `mudflap_finish_file' into a synthetic constructor
- function containing calls into the mudflap runtime.
-
- * 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.
-
-
-\1f
-File: gccint.info, Node: Trees, Next: GENERIC, Prev: Passes, Up: Top
-
-9 Trees: The intermediate representation used by the C and C++ front ends
-*************************************************************************
-
-This chapter 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 chapter 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.
-
- 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:
-
-* Deficiencies:: Topics net yet covered in this document.
-* Tree overview:: All about `tree's.
-* Types:: Fundamental and aggregate types.
-* Scopes:: Namespaces and classes.
-* Functions:: Overloading, function bodies, and linkage.
-* Declarations:: Type declarations and variables.
-* Attributes:: Declaration and type attributes.
-* Expression trees:: From `typeid' to `throw'.
-
-\1f
-File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees
-
-9.1 Deficiencies
-================
-
-There are many places in which this document is incomplet and incorrekt.
-It is, as of yet, only _preliminary_ documentation.
-
-\1f
-File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees
-
-9.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.
-
-\1f
-File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview
-
-9.2.1 Trees
------------
-
-This section is not here yet.
-
-\1f
-File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview
-
-9.2.2 Identifiers
------------------
-
-An `IDENTIFIER_NODE' represents a slightly more general concept that
-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'.
-
- 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.
-
-
-\1f
-File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview
-
-9.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.
-
-\1f
-File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees
-
-9.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.
-
- 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 macro 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.
-
-`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 a `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_PTRMEM_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 *'.
-
-`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. If the
- type is a pointer to data member type, then `TYPE_PTRMEM_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'.
-
-`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.
- 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, see *note Classes::.
-
-`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'.
-
-`UNKNOWN_TYPE'
- This node is used to represent a type the knowledge of which is
- insufficient for a sound processing.
-
-`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'.
-
-`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.
-
- 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'.
-
-\1f
-File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees
-
-9.4 Scopes
-==========
-
-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.
-
- 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.)
-
-* Menu:
-
-* Namespaces:: Member functions, types, etc.
-* Classes:: Members, bases, friends, etc.
-
-\1f
-File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes
-
-9.4.1 Namespaces
-----------------
-
-A namespace is represented by a `NAMESPACE_DECL' node.
-
- 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.
-
- 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.
-
-
-\1f
-File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes
-
-9.4.2 Classes
--------------
-
-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.
-
-
-\1f
-File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees
-
-9.5 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.
-
-\1f
-File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations
-
-9.5.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.
-
-`TREE_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>"'.
-
-`TREE_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.
-
-`DECL_NAMESPACE_SCOPE_P'
- This predicate holds if the entity was declared at a namespace
- scope.
-
-`DECL_CLASS_SCOPE_P'
- This predicate holds if the entity was declared at a class scope.
-
-`DECL_FUNCTION_SCOPE_P'
- This predicate holds if the entity was declared inside a function
- body.
-
-
- 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'.
-
-`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'
- *Note Namespaces::.
-
-`TEMPLATE_DECL'
- These nodes are used to represent class, function, and variable
- (static data member) templates. The
- `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The
- `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or
- `FUNCTION_DECL's representing specializations (including
- instantiations) of this template. Back ends can safely ignore
- `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the
- specializations list just as they would ordinary `FUNCTION_DECL'
- nodes.
-
- For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list
- contains the instantiations. The `TREE_VALUE' of each node is an
- instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS'
- contains partial specializations of the class.
-
-`USING_DECL'
- Back ends can safely ignore these nodes.
-
-
-\1f
-File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations
-
-9.5.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.
-
-\1f
-File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure
-
-9.5.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'.
-
-
-\1f
-File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure
-
-9.5.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
-
-
-\1f
-File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees
-
-9.6 Functions
-=============
-
-A function is represented by a `FUNCTION_DECL' node. A set of
-overloaded functions is sometimes represented by a `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'.
-
- 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.
-
-* Menu:
-
-* Function Basics:: Function names, linkage, and so forth.
-* Function Bodies:: The statements that make up a function body.
-
-\1f
-File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions
-
-9.6.1 Function Basics
----------------------
-
-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_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_EXTERNAL'
- This predicate holds if the function is undefined.
-
-`TREE_PUBLIC'
- This predicate holds if the function has external linkage.
-
-`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.
-
-`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_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.
-
-`TREE_TYPE'
- This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the
- function.
-
-`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[]'.
-
-`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.
-
-\1f
-File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions
-
-9.6.2 Function Bodies
----------------------
-
-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.
-
-9.6.2.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.
-
-`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'.
-
-`BREAK_STMT'
- Used to represent a `break' statement. There are no additional
- fields.
-
-`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'.
-
-`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.
-
-`DECL_STMT'
- Used to represent a local declaration. The `DECL_STMT_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::.
-
-`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.
-
-`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.
-
-`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:
-
- 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.
-
-`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'.
-
-`RETURN_STMT'
- Used to represent a `return' statement. The `RETURN_EXPR' is the
- expression returned; it will be `NULL_TREE' if the statement was
- just
- return;
-
-`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.
-
-
-\1f
-File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees
-
-9.7 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.
-
-\1f
-File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees
-
-9.8 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.
-
- All the expressions starting with `OMP_' represent directives and
-clauses used by the OpenMP API `http://www.openmp.org/'.
-
- 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 to 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.
-
-`PTRMEM_CST'
- These nodes are used to represent pointer-to-member constants. The
- `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or
- `UNION_TYPE' within which the pointer points), and the
- `PTRMEM_CST_MEMBER' is the declaration for the pointed to object.
- Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in
- general different from the `PTRMEM_CST_CLASS'. For example, given:
- struct B { int i; };
- struct D : public B {};
- int D::*dp = &D::i;
- The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the
- `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is
- a member of `B', not `D'.
-
-`VAR_DECL'
- These nodes represent variables, including static data members.
- For more information, *note Declarations::.
-
-`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.
-
-`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.
-
-`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.
-
-`THROW_EXPR'
- These nodes represent `throw' expressions. The single operand is
- an expression for the code that should be executed to throw the
- exception. However, there is one implicit action not represented
- in that expression; namely the call to `__throw'. This function
- takes no arguments. If `setjmp'/`longjmp' exceptions are used, the
- function `__sjthrow' is called instead. The normal GCC back end
- uses the function `emit_throw' to generate this code; you can
- examine this function to see what needs to be done.
-
-`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.
-
-`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.
-
-`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.
-
-`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.
-
-`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 operand with either be both of
- integral type or both of floating type. 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.
-
- 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.
-
-`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.
-
-`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.
-
-`STMT_EXPR'
- These nodes are used to represent GCC's statement-expression
- extension. The statement-expression extension allows code like
- this:
- int f() { return ({ int j; j = 3; j + 7; }); }
- In other words, an sequence of statements may occur where a single
- expression would normally appear. The `STMT_EXPR' node represents
- such an expression. The `STMT_EXPR_STMT' gives the statement
- contained in the expression. The value of the expression is the
- value of the last sub-statement in the body. More precisely, the
- value is the value computed by the last statement nested inside
- `BIND_EXPR', `TRY_FINALLY_EXPR', or `TRY_CATCH_EXPR'. For
- example, in:
- ({ 3; })
- the value is `3' while in:
- ({ if (x) { 3; } })
- there is no value. If the `STMT_EXPR' does not yield a value,
- it's type will be `void'.
-
-`BIND_EXPR'
- These nodes represent local blocks. The first operand is a list of
- variables, connected via their `TREE_CHAIN' field. These will
- never require cleanups. The scope of these variables is just the
- body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the
- second operand.
-
-`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'.
-
-`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 array. The first operand is reserved for use by the
- back end. The second operand is a `TREE_LIST'. If the
- `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
- `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
- `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
- node will be the expression used to initialize that field.
-
- If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
- the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
- `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single
- `INTEGER_CST' indicates which element of the array (indexed from
- zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive
- range of elements to initialize. In both cases the `TREE_VALUE'
- is the corresponding initializer. It is re-evaluated for each
- element of a `RANGE_EXPR'. If the `TREE_PURPOSE' 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 set to
- zero.
-
-`COMPOUND_LITERAL_EXPR'
- These nodes represent ISO C99 compound literals. The
- `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' 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.
-
- See `STMT_IS_FULL_EXPR_P' for more information about running these
- cleanups.
-
-`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.
-
-`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'.
-
-`CHANGE_DYNAMIC_TYPE_EXPR'
- Indicates the special aliasing required by C++ placement new. It
- has two operands: a type and a location. It means that the
- dynamic type of the location is changing to be the specified type.
- The alias analysis code takes this into account when doing type
- based alias analysis.
-
-`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 sub-codes 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',
- and `OMP_CLAUSE_REDUCTION'. 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.
-
-`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_EXTRACT_EVEN_EXPR'
-
-`VEC_EXTRACT_ODD_EXPR'
- These nodes represent extracting of the even/odd elements of the
- two input vectors, respectively. Their operands and result are
- vectors that contain the same number of elements of the same type.
-
-`VEC_INTERLEAVE_HIGH_EXPR'
-
-`VEC_INTERLEAVE_LOW_EXPR'
- These nodes represent merging and interleaving of the high/low
- elements of the two input vectors, respectively. The operands and
- the result are vectors that contain the same number of elements
- (`N') of the same type. In the case of
- `VEC_INTERLEAVE_HIGH_EXPR', the high `N/2' elements of the first
- input vector are interleaved with the high `N/2' elements of the
- second input vector. In the case of `VEC_INTERLEAVE_LOW_EXPR', the
- low `N/2' elements of the first input vector are interleaved with
- the low `N/2' elements of the second input vector.
-
-
-\1f
-File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top
-
-10 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.
-* 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.
-
-\1f
-File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL
-
-10.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)'.
-
-\1f
-File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL
-
-10.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' and `VEC_MERGE'.
-
-`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.
-
-\1f
-File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL
-
-10.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 (X)'
- The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.
-
- `MEM_SIZE (X)'
- The size in bytes of the memory reference as a `CONST_INT'
- rtx. This is mostly relevant for `BLKmode' references as
- otherwise the size is implied by the mode.
-
- `MEM_ALIGN (X)'
- The known alignment in bits of the memory reference.
-
-`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.
-
-\1f
-File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL
-
-10.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', `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_IN_STRUCT_P (X)'
- In `mem' expressions, nonzero for reference to an entire structure,
- union or array, or to a component of one. Zero for references to a
- scalar variable or through a pointer to a scalar. If both this
- flag and `MEM_SCALAR_P' are clear, then we don't know whether this
- `mem' is in a structure or not. Both flags should never be
- simultaneously set. Stored in the `in_struct' field and printed
- as `/s'.
-
-`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_SCALAR_P (X)'
- In `mem' expressions, nonzero for reference to a scalar known not
- to be a member of a structure, union, or array. Zero for such
- references and for indirections through pointers, even pointers
- pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P'
- are clear, then we don't know whether this `mem' is in a structure
- or not. Both flags should never be simultaneously set. Stored in
- the `return_val' field and printed as `/i'.
-
-`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 transfered
- 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' or
- `jump_insn', 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.
-
- 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 `mem' expressions, it is 1 if the memory datum referred to is
- all or part of a structure or array; 0 if it is (or might be) a
- scalar variable. A reference through a C pointer has 0 because
- the pointer might point to a scalar variable. This information
- allows the compiler to determine something about possible cases of
- aliasing.
-
- 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 `mem' expressions, 1 means the memory reference is to a scalar
- known not to be a member of a structure, union, or array.
-
- 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 an RTL dump, this flag is represented as `/v'.
-
-\1f
-File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
-
-10.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.
-
-`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' (see *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 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.
-
-\1f
-File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
-
-10.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 `HOST_WIDE_INT'
- must be sign extended to full width (e.g., with `gen_int_mode').
-
- 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'.
-
- 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.
-
-\1f
-File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
-
-10.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'.
-
-`(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)'
- Represents the absolute value of X, computed in mode M.
-
-`(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 need not be M; depending on the target
- machine, various mode combinations may be valid.
-
-`(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 will usually be an integer mode.
-
-`(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 will
- usually be an integer mode.
-
-`(popcount:M X)'
- Represents the number of 1-bits in X, represented as an integer of
- mode M. The mode of X will usually be an integer mode.
-
-`(parity:M X)'
- Represents the number of 1-bits modulo 2 in X, represented as an
- integer of mode M. The mode of X will usually be an integer mode.
-
-`(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.
-
-\1f
-File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL
-
-10.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::.
-
-\1f
-File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL
-
-10.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, 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.
-
-`(vec_concat:M VEC1 VEC2)'
- Describes a vector concat operation. The result is a
- concatenation of the vectors VEC1 and VEC2; its length is the sum
- of the lengths of the two inputs.
-
-`(vec_duplicate:M VEC)'
- This operation converts 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, and the number of
- output parts must be an integer multiple of the number of input
- parts.
-
-
-\1f
-File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
-
-10.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.
-
-`(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.
- An 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',
- `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. Each of the INSNS that appears in
- the vector is suitable for appearing in the chain of insns, so it
- must be an `insn', `jump_insn', `call_insn', `code_label',
- `barrier' or `note'.
-
- A `sequence' RTX is never placed in an actual insn during RTL
- generation. It represents the sequence of insns that result from a
- `define_expand' _before_ those insns are passed to `emit_insn' to
- insert them in the chain of insns. When actually inserted, the
- individual sub-insns are separated out and the `sequence' is
- forgotten.
-
- 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::.
-
- 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.
-
-\1f
-File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
-
-10.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.
-
-\1f
-File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
-
-10.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 a
-`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.
-
-\1f
-File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
-
-10.18 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 six 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' and `clobber'
- expressions that denote hard registers and `MEM's used or
- clobbered by the called function.
-
- A `MEM' generally points to a stack slots 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.
-
- `CLOBBER'ed registers in this list augment registers specified in
- `CALL_USED_REGISTERS' (*note Register Basics::).
-
-`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.
-
-`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_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note'
- of type `NOTE_INSN_DELETED_LABEL' is associated with the
- given region.
-
- `NOTE_INSN_LOOP_BEG'
- `NOTE_INSN_LOOP_END'
- These types of notes indicate the position of the beginning
- and end of a `while' or `for' loop. They enable the loop
- optimizer to find loops quickly.
-
- `NOTE_INSN_LOOP_CONT'
- Appears at the place in a loop that `continue' statements
- jump to.
-
- `NOTE_INSN_LOOP_VTOP'
- This note indicates the place in a loop where the exit test
- begins for those loops in which the exit test has been
- duplicated. This position becomes another virtual start of
- the loop when considering loop invariants.
-
- `NOTE_INSN_FUNCTION_BEG'
- Appears at the start of the function body, after the function
- prologue.
-
-
- These codes are printed symbolically when they appear in debugging
- dumps.
-
- 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', `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' and `insn_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' 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 a `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 an 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 as an `expr_list'.
-
-`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 value is stored as
- a value 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.
-
-\1f
-File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
-
-10.19 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.
-
-\1f
-File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
-
-10.20 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'.
-
-\1f
-File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL
-
-10.21 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 Trees::) is
-incomplete.
-
-\1f
-File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Trees, Up: Top
-
-11 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 most
-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.
-
- 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.
-
-* Menu:
-
-* Statements::
-
-\1f
-File: gccint.info, Node: Statements, Up: GENERIC
-
-11.1 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:
-
-* Blocks::
-* Statement Sequences::
-* Empty Statements::
-* Jumps::
-* Cleanups::
-
-\1f
-File: gccint.info, Node: Blocks, Next: Statement Sequences, Up: Statements
-
-11.1.1 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. 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'.
-
- 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'.
-
-\1f
-File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements
-
-11.1.2 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'.
-
-\1f
-File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements
-
-11.1.3 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'.
-
-\1f
-File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements
-
-11.1.4 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'.
-
-\1f
-File: gccint.info, Node: Cleanups, Prev: Jumps, Up: Statements
-
-11.1.5 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'.
-
-\1f
-File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top
-
-12 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::
-
-\1f
-File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE
-
-12.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.
-
-12.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.
-
-12.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
-`addresses_taken' 64
-`def_ops' 64
-`use_ops' 64
-`op' `num_ops' * 64
-Total size 56 + 8 * `num_ops' bytes
-
- * `gsbase' Inherited from `struct gimple_statement_base'.
-
- * `addresses_taken' Bitmap holding the UIDs of all the `VAR_DECL's
- whose addresses are taken by this statement. For example, a
- statement of the form `p = &b' will have the UID for symbol `b' in
- this set.
-
- * `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.
-
-12.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
-`addresses_taken' 64
-`def_ops' 64
-`use_ops' 64
-`vdef_ops' 64
-`vuse_ops' 64
-`stores' 64
-`loads' 64
-`op' `num_ops' * 64
-Total size 88 + 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;
- };
-
-\1f
-File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE
-
-12.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_CHANGE_DYNAMIC_TYPE' x x
-`GIMPLE_COND' 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
-
-\1f
-File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE
-
-12.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. An `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'.
-
-\1f
-File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE
-
-12.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.
-
-\1f
-File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE
-
-12.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 an
-`INDIRECT_REF' or a compound lvalue as described below.
-
-* Menu:
-
-* Compound Expressions::
-* Compound Lvalues::
-* Conditional Expressions::
-* Logical Operators::
-
-\1f
-File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands
-
-12.5.1 Compound Expressions
----------------------------
-
-The left-hand side of a C comma expression is simply moved into a
-separate statement.
-
-\1f
-File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands
-
-12.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.
-
-\1f
-File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands
-
-12.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.
-
-\1f
-File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands
-
-12.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.
-
-12.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_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_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>>
-
-12.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.
-
-12.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: is_gimple_operand (tree t)
- This is the most permissive of the predicates. It essentially
- checks whether t has a `gimple_rhs_class' of `GIMPLE_SINGLE_RHS'.
-
- -- GIMPLE function: 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: is_gimple_addressable (tree t)
- Returns true if t is a symbol or memory reference whose address
- can be taken.
-
- -- GIMPLE function: is_gimple_asm_val (tree t)
- Similar to `is_gimple_val' but it also accepts hard registers.
-
- -- GIMPLE function: 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: is_gimple_constant (tree t)
- Return true if t is a valid gimple constant.
-
- -- GIMPLE function: 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: is_gimple_min_invariant_address (tree t)
- Return true if t is an `ADDR_EXPR' that does not change once the
- program is running.
-
-12.5.8 Statement validation
----------------------------
-
- -- GIMPLE function: is_gimple_assign (gimple g)
- Return true if the code of g is `GIMPLE_ASSIGN'.
-
- -- GIMPLE function: is_gimple_call (gimple g)
- Return true if the code of g is `GIMPLE_CALL'
-
- -- GIMPLE function: gimple_assign_cast_p (gimple g)
- Return true if g is a `GIMPLE_ASSIGN' that performs a type cast
- operation
-
-\1f
-File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE
-
-12.6 Manipulating GIMPLE statements
-===================================
-
-This section documents all the functions available to handle each of
-the GIMPLE instructions.
-
-12.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'.
-
-\1f
-File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE
-
-12.7 Tuple specific accessors
-=============================
-
-* Menu:
-
-* `GIMPLE_ASM'::
-* `GIMPLE_ASSIGN'::
-* `GIMPLE_BIND'::
-* `GIMPLE_CALL'::
-* `GIMPLE_CATCH'::
-* `GIMPLE_CHANGE_DYNAMIC_TYPE'::
-* `GIMPLE_COND'::
-* `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'::
-
-\1f
-File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors
-
-12.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: gimple_asm_ninputs (gimple g)
- Return the number of input operands for `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: gimple_asm_noutputs (gimple g)
- Return the number of output operands for `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: 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.
-
- -- GIMPLE function: void gimple_asm_clear_volatile (gimple g)
- Remove volatile marker from asm statement `G'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors
-
-12.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: 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: 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 a pointer to the second 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: bool gimple_assign_cast_p (gimple s)
- Return true if `S' is an type-cast assignment.
-
-\1f
-File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors
-
-12.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: 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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_CHANGE_DYNAMIC_TYPE', Prev: `GIMPLE_CALL', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_CHANGE_DYNAMIC_TYPE', Next: `GIMPLE_COND', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors
-
-12.7.6 `GIMPLE_CHANGE_DYNAMIC_TYPE'
------------------------------------
-
- -- GIMPLE function: gimple gimple_build_cdt (tree type, tree ptr)
- Build a `GIMPLE_CHANGE_DYNAMIC_TYPE' statement. `TYPE' is the new
- type for the location `PTR'.
-
- -- GIMPLE function: tree gimple_cdt_new_type (gimple g)
- Return the new type set by `GIMPLE_CHANGE_DYNAMIC_TYPE' statement
- `G'.
-
- -- GIMPLE function: tree *gimple_cdt_new_type_ptr (gimple g)
- Return a pointer to the new type set by
- `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
-
- -- GIMPLE function: void gimple_cdt_set_new_type (gimple g, tree
- new_type)
- Set `NEW_TYPE' to be the type returned by
- `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
-
- -- GIMPLE function: tree gimple_cdt_location (gimple g)
- Return the location affected by `GIMPLE_CHANGE_DYNAMIC_TYPE'
- statement `G'.
-
- -- GIMPLE function: tree *gimple_cdt_location_ptr (gimple g)
- Return a pointer to the location affected by
- `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
-
- -- GIMPLE function: void gimple_cdt_set_location (gimple g, tree ptr)
- Set `PTR' to be the location affected by
- `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_CHANGE_DYNAMIC_TYPE', Up: Tuple specific accessors
-
-12.7.7 `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)'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_COND', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors
-
-12.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'.
-
- -- GIMPLE function: bool is_gimple_omp (gimple stmt)
- Returns true when the gimple statement `STMT' is any of the OpenMP
- types.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors
-
-12.7.23 `GIMPLE_PHI'
---------------------
-
- -- GIMPLE function: gimple make_phi_node (tree var, int len)
- Build a `PHI' node with len argument slots for variable var.
-
- -- 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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors
-
-12.7.26 `GIMPLE_SWITCH'
------------------------
-
- -- GIMPLE function: gimple gimple_build_switch ( nlabels, tree index,
- tree default_label, ...)
- Build a `GIMPLE_SWITCH' statement. `NLABELS' are the number of
- labels excluding the default label. The default label is passed
- in `DEFAULT_LABEL'. The rest of the arguments are trees
- representing the labels. Each label is a tree of code
- `CASE_LABEL_EXPR'.
-
- -- GIMPLE function: gimple gimple_build_switch_vec (tree index, tree
- default_label, `VEC'(tree,heap) *args)
- This function is an alternate way of building `GIMPLE_SWITCH'
- statements. `INDEX' and `DEFAULT_LABEL' are as in
- gimple_build_switch. `ARGS' is a vector of `CASE_LABEL_EXPR' trees
- that contain the labels.
-
- -- 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.
-
-\1f
-File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors
-
-12.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'.
-
-\1f
-File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors
-
-12.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.
-
-\1f
-File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE
-
-12.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.
-
-\1f
-File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE
-
-12.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.
-
-\1f
-File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE
-
-12.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'.
-
-\1f
-File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE
-
-12.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', `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.
-
-\1f
-File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top
-
-13 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.
-
-\1f
-File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA
-
-13.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'.
-
- Presently, we define annotations for variables (`var_ann_t').
-Annotations are defined and documented in `tree-flow.h'.
-
-\1f
-File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA
-
-13.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 `b' is
-completely modified with the contents of variable `a'. Real definition
-are also known as "killing definitions". Similarly, the use of `a'
-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'.
-
-13.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_VMAYUSE 0x08 /* USE portion of VDEFS. */
- #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */
-
- /* These are commonly grouped operand flags. */
- #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE)
- #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF)
- #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_VMAYUSE'). If all
-you want to look at are the `VDEF's together, there is a fourth
-iterator macro for this, which returns both a def_operand_p and a
-use_operand_p for each `VDEF' in the statement. Note that you don't
-need any flags for this one.
-
- use_operand_p use_p;
- def_operand_p def_p;
- ssa_op_iter iter;
-
- FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
- {
- my_code;
- }
-
- There are many examples in the code as well, as well as the
-documentation in `tree-ssa-operands.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;
- }
-
-13.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));
- }
-
-\1f
-File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA
-
-13.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 macros can be used to examine PHI nodes
-
- -- Macro: PHI_RESULT (PHI)
- Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
-
- -- Macro: 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.
-
- -- Macro: PHI_ARG_ELT (PHI, I)
- Returns a tuple representing the Ith argument of PHI. Each
- element of this tuple contains an `SSA_NAME' VAR and the incoming
- edge through which VAR flows.
-
- -- Macro: PHI_ARG_EDGE (PHI, I)
- Returns the incoming edge for the Ith argument of PHI.
-
- -- Macro: PHI_ARG_DEF (PHI, I)
- Returns the `SSA_NAME' for the Ith argument of PHI.
-
-13.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). On the other hand, if your pass
-exposes a new symbol that should be put in SSA form for the first time,
-the new symbol should be registered with `mark_sym_for_renaming'.
-
- 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.
-
-13.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.
-
-13.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.
-
-13.3.4 Walking use-def chains
------------------------------
-
- -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA)
- Walks use-def chains starting at the `SSA_NAME' node VAR. Calls
- function FN at each reaching definition found. Function FN takes
- three arguments: VAR, its defining statement (DEF_STMT) and a
- generic pointer to whatever state information that FN may want to
- maintain (DATA). Function FN is able to stop the walk by
- returning `true', otherwise in order to continue the walk, FN
- should return `false'.
-
- Note, that if DEF_STMT is a `PHI' node, the semantics are slightly
- different. For each argument ARG of the PHI node, this function
- will:
-
- 1. Walk the use-def chains for ARG.
-
- 2. Call `FN (ARG, PHI, DATA)'.
-
- Note how the first argument to FN is no longer the original
- variable VAR, but the PHI argument currently being examined. If
- FN wants to get at VAR, it should call `PHI_RESULT' (PHI).
-
-13.3.5 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.
-
-\1f
-File: gccint.info, Node: Alias analysis, Prev: SSA, Up: Tree SSA
-
-13.4 Alias analysis
-===================
-
-Alias analysis proceeds in 4 main phases:
-
- 1. Structural alias analysis.
-
- This phase walks the types for structure variables, and determines
- which of the fields can overlap using offset and size of each
- field. For each field, a "subvariable" called a "Structure field
- tag" (SFT) is created, which represents that field as a separate
- variable. All accesses that could possibly overlap with a given
- field will have virtual operands for the SFT of that field.
-
- struct foo
- {
- int a;
- int b;
- }
- struct foo temp;
- int bar (void)
- {
- int tmp1, tmp2, tmp3;
- SFT.0_2 = VDEF <SFT.0_1>
- temp.a = 5;
- SFT.1_4 = VDEF <SFT.1_3>
- temp.b = 6;
-
- VUSE <SFT.1_4>
- tmp1_5 = temp.b;
- VUSE <SFT.0_2>
- tmp2_6 = temp.a;
-
- tmp3_7 = tmp1_5 + tmp2_6;
- return tmp3_7;
- }
-
- If you copy the symbol tag for a variable for some reason, you
- probably also want to copy the subvariables for that variable.
-
- 2. Points-to and escape analysis.
-
- This phase walks the use-def chains in the SSA web looking for
- three things:
-
- * Assignments of the form `P_i = &VAR'
-
- * Assignments of the form P_i = malloc()
-
- * Pointers and ADDR_EXPR that escape the current function.
-
- The concept of `escaping' is the same one used in the Java world.
- When a pointer or an ADDR_EXPR escapes, it means that it has been
- exposed outside of the current function. So, assignment to global
- variables, function arguments and returning a pointer are all
- escape sites.
-
- This is where we are currently limited. Since not everything is
- renamed into SSA, we lose track of escape properties when a
- pointer is stashed inside a field in a structure, for instance.
- In those cases, we are assuming that the pointer does escape.
-
- We use escape analysis to determine whether a variable is
- call-clobbered. Simply put, if an ADDR_EXPR escapes, then the
- variable is call-clobbered. If a pointer P_i escapes, then all
- the variables pointed-to by P_i (and its memory tag) also escape.
-
- 3. Compute flow-sensitive aliases
-
- We have two classes of memory tags. Memory tags associated with
- the pointed-to data type of the pointers in the program. These
- tags are called "symbol memory tag" (SMT). The other class are
- those associated with SSA_NAMEs, called "name memory tag" (NMT).
- The basic idea is that when adding operands for an INDIRECT_REF
- *P_i, we will first check whether P_i has a name tag, if it does
- we use it, because that will have more precise aliasing
- information. Otherwise, we use the standard symbol tag.
-
- In this phase, we go through all the pointers we found in
- points-to analysis and create alias sets for the name memory tags
- associated with each pointer P_i. If P_i escapes, we mark
- call-clobbered the variables it points to and its tag.
-
- 4. Compute flow-insensitive aliases
-
- This pass will compare the alias set of every symbol memory tag and
- every addressable variable found in the program. Given a symbol
- memory tag SMT and an addressable variable V. If the alias sets
- of SMT and V conflict (as computed by may_alias_p), then V is
- marked as an alias tag and added to the alias set of SMT.
-
- 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'.
-
- For instance, consider the following function:
-
- foo (int i)
- {
- int *p, *q, a, b;
-
- if (i > 10)
- p = &a;
- else
- q = &b;
-
- *p = 3;
- *q = 5;
- a = b + 2;
- return *p;
- }
-
- After aliasing analysis has finished, the symbol memory tag for
-pointer `p' will have two aliases, namely variables `a' and `b'. Every
-time pointer `p' is dereferenced, we want to mark the operation as a
-potential reference to `a' and `b'.
-
- foo (int i)
- {
- int *p, a, b;
-
- if (i_2 > 10)
- p_4 = &a;
- else
- p_6 = &b;
- # p_1 = PHI <p_4(1), p_6(2)>;
-
- # a_7 = VDEF <a_3>;
- # b_8 = VDEF <b_5>;
- *p_1 = 3;
-
- # a_9 = VDEF <a_7>
- # VUSE <b_8>
- a_9 = b_8 + 2;
-
- # VUSE <a_9>;
- # VUSE <b_8>;
- return *p_1;
- }
-
- In certain cases, the list of may aliases for a pointer may grow too
-large. This may cause an explosion in the number of virtual operands
-inserted in the code. Resulting in increased memory consumption and
-compilation time.
-
- When the number of virtual operands needed to represent aliased loads
-and stores grows too large (configurable with `--param
-max-aliased-vops'), alias sets are grouped to avoid severe compile-time
-slow downs and memory consumption. The alias grouping heuristic
-proceeds as follows:
-
- 1. Sort the list of pointers in decreasing number of contributed
- virtual operands.
-
- 2. Take the first pointer from the list and reverse the role of the
- memory tag and its aliases. Usually, whenever an aliased variable
- Vi is found to alias with a memory tag T, we add Vi to the
- may-aliases set for T. Meaning that after alias analysis, we will
- have:
-
- may-aliases(T) = { V1, V2, V3, ..., Vn }
-
- This means that every statement that references T, will get `n'
- virtual operands for each of the Vi tags. But, when alias
- grouping is enabled, we make T an alias tag and add it to the
- alias set of all the Vi variables:
-
- may-aliases(V1) = { T }
- may-aliases(V2) = { T }
- ...
- may-aliases(Vn) = { T }
-
- This has two effects: (a) statements referencing T will only get a
- single virtual operand, and, (b) all the variables Vi will now
- appear to alias each other. So, we lose alias precision to
- improve compile time. But, in theory, a program with such a high
- level of aliasing should not be very optimizable in the first
- place.
-
- 3. Since variables may be in the alias set of more than one memory
- tag, the grouping done in step (2) needs to be extended to all the
- memory tags that have a non-empty intersection with the
- may-aliases set of tag T. For instance, if we originally had
- these may-aliases sets:
-
- may-aliases(T) = { V1, V2, V3 }
- may-aliases(R) = { V2, V4 }
-
- In step (2) we would have reverted the aliases for T as:
-
- may-aliases(V1) = { T }
- may-aliases(V2) = { T }
- may-aliases(V3) = { T }
-
- But note that now V2 is no longer aliased with R. We could add R
- to may-aliases(V2), but we are in the process of grouping aliases
- to reduce virtual operands so what we do is add V4 to the grouping
- to obtain:
-
- may-aliases(V1) = { T }
- may-aliases(V2) = { T }
- may-aliases(V3) = { T }
- may-aliases(V4) = { T }
-
- 4. If the total number of virtual operands due to aliasing is still
- above the threshold set by max-alias-vops, go back to (2).
-
-\1f
-File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top
-
-14 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.
-* Lambda:: Linear loop transformations framework.
-* Omega:: A solver for linear programming problems.
-
-\1f
-File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation
-
-14.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'. At
-the moment, loop structures are analyzed and this information is
-updated only by the optimization passes that deal with loops, but some
-efforts are being made to make it available throughout most of the
-optimization 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 memory occupied by the loops structures should be freed with
-`loop_optimizer_finalize' function.
-
- 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.
-
-\1f
-File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation
-
-14.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).
-
-\1f
-File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation
-
-14.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.
-
-\1f
-File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation
-
-14.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.
-
-\1f
-File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation
-
-14.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.
-
-\1f
-File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation
-
-14.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.
-
-\1f
-File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation
-
-14.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).
-
-\1f
-File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation
-
-14.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.
-
-\1f
-File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation
-
-14.9 Linear loop transformations framework
-==========================================
-
-Lambda is a framework that allows transformations of loops using
-non-singular matrix based transformations of the iteration space and
-loop bounds. This allows compositions of skewing, scaling, interchange,
-and reversal transformations. These transformations are often used to
-improve cache behavior or remove inner loop dependencies to allow
-parallelization and vectorization to take place.
-
- To perform these transformations, Lambda requires that the loopnest be
-converted into a internal form that can be matrix transformed easily.
-To do this conversion, the function `gcc_loopnest_to_lambda_loopnest'
-is provided. If the loop cannot be transformed using lambda, this
-function will return NULL.
-
- Once a `lambda_loopnest' is obtained from the conversion function, it
-can be transformed by using `lambda_loopnest_transform', which takes a
-transformation matrix to apply. Note that it is up to the caller to
-verify that the transformation matrix is legal to apply to the loop
-(dependence respecting, etc). Lambda simply applies whatever matrix it
-is told to provide. It can be extended to make legal matrices out of
-any non-singular matrix, but this is not currently implemented.
-Legality of a matrix for a given loopnest can be verified using
-`lambda_transform_legal_p'.
-
- Given a transformed loopnest, conversion back into gcc IR is done by
-`lambda_loopnest_to_gcc_loopnest'. This function will modify the loops
-so that they match the transformed loopnest.
-
-\1f
-File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation
-
-14.10 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'.
-
-\1f
-File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top
-
-15 Control Flow Graph
-*********************
-
-A control flow graph (CFG) is a data structure built on top of the
-intermediate code representation (the RTL or `tree' 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'.
-
-* 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.
-
-\1f
-File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow
-
-15.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.
-
- 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. 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.
-
- 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'.
-
- 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, and are not
-elements of the `BASIC_BLOCK' array. Therefore they have been assigned
-unique, negative index numbers.
-
- 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 (`tree' and RTL), there are
-pointers to the head and end of a basic block for both representations.
-
- For RTL, these pointers are `rtx head, end'. In the RTL function
-representation, the head pointer always points either to a
-`NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL
-representation of a function, the instruction stream contains not only
-the "real" instructions, but also "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, making such updates difficult. The
-`NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear
-in the instruction stream contained in a basic block. The instruction
-stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but
-zero or more `CODE_LABEL' nodes can precede the block note. A basic
-block ends by control flow instruction or last instruction before
-following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL'
-cannot appear in 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 `tree' representation, the head and end of the basic block are
-being pointed to by the `stmt_list' field, but this special `tree'
-should never be referenced directly. Instead, at the tree level
-abstract containers and iterators are used to access statements and
-expressions in basic blocks. These iterators are called "block
-statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*'
-files. The following snippet will pretty-print all the statements of
-the program in the GIMPLE representation.
-
- FOR_EACH_BB (bb)
- {
- block_stmt_iterator si;
-
- for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
- {
- tree stmt = bsi_stmt (si);
- print_generic_stmt (stderr, stmt, 0);
- }
- }
-
-\1f
-File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow
-
-15.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, 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 `tree' 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. 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 `tree' 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.
-
-
-\1f
-File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow
-
-15.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.
-
-\1f
-File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow
-
-15.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 `tree'
-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). Often the CFG may be better viewed as
-integral part of instruction chain, than structure built on the top of
-it. However, in principle the control flow graph for the `tree'
-representation is _not_ an integral part of the representation, in that
-a function tree may be expanded without first building a flow graph
-for the `tree' representation at all. This happens when compiling
-without any `tree' optimization enabled. When the `tree' optimizations
-are enabled and the instruction stream is rewritten in SSA form, the
-CFG is very tightly coupled with the instruction stream. In
-particular, statement insertion and removal has to be done with care.
-In fact, the whole `tree' representation can not be easily used or
-maintained without proper maintenance of the CFG simultaneously.
-
- 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 `tree' representation, the function `bb_for_stmt'
-returns a pointer to the basic block containing the queried statement.
-
- When changes need to be applied to a function in its `tree'
-representation, "block 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 `block_stmt_iterator' data structure and several modifier are
-available, including the following:
-
-`bsi_start'
- This function initializes a `block_stmt_iterator' that points to
- the first non-empty statement in a basic block.
-
-`bsi_last'
- This function initializes a `block_stmt_iterator' that points to
- the last statement in a basic block.
-
-`bsi_end_p'
- This predicate is `true' if a `block_stmt_iterator' represents the
- end of a basic block.
-
-`bsi_next'
- This function takes a `block_stmt_iterator' and makes it point to
- its successor.
-
-`bsi_prev'
- This function takes a `block_stmt_iterator' and makes it point to
- its predecessor.
-
-`bsi_insert_after'
- This function inserts a statement after the `block_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.
-
-`bsi_insert_before'
- This function inserts a statement before the `block_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.
-
-`bsi_remove'
- This function removes the `block_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. See *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 `tree' representation, the equivalent
-functions are `bsi_insert_on_edge' which inserts a block statement
-iterator on an edge, and `bsi_commit_edge_inserts' which flushes the
-instruction to actual instruction stream.
-
- While debugging the optimization pass, an `verify_flow_info' function
-may be useful to find bugs in the control flow graph updating code.
-
- Note that at present, the representation of control flow in the `tree'
-representation is discarded before expanding to RTL. Long term the CFG
-should be maintained and "expanded" to the RTL representation along
-with the function `tree' itself.
-
-\1f
-File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow
-
-15.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 uses 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.
-
-\1f
-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.
-* Constant Definitions::Defining symbolic constants that can be used in the
- md file.
-* Iterators:: Using iterators to generate patterns from a template.
-
-\1f
-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.
-
-\1f
-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::.
-
-\1f
-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.
-
-\1f
-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'.
-
-
-\1f
-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 an 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::.
-
-\1f
-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")
-
-\1f
-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.
-
-\1f
-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 is one generic operator predicate.
-
- -- 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.
-
-\1f
-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'.
-
-\1f
-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.
-
-* 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.
-* Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute.
-* Machine Constraints:: Existing constraints for some particular machines.
-* Define Constraints:: How to define machine-specific constraints.
-* C Constraint Interface:: How to test constraints from C code.
-
-\1f
-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.
-
-`>'
- A memory operand with autoincrement addressing (either
- preincrement or postincrement) is allowed.
-
-`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'.
-
-\1f
-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::.
-
-\1f
-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.
-
-\1f
-File: gccint.info, Node: Modifiers, Next: Disable Insn Alternatives, 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.
-
- 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")))]
- ...)
-
-\1f
-File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Disable Insn Alternatives, 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.
-
-_ARM family--`config/arm/arm.h'_
-
- `f'
- Floating-point register
-
- `w'
- VFP floating-point register
-
- `F'
- One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
- 4.0, 5.0 or 10.0
-
- `G'
- Floating-point constant that would satisfy the constraint `F'
- if it were negated
-
- `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
-
- `R'
- Integer constant in the range -6 ... 5.
-
- `Q'
- A memory address based on Y or Z pointer with displacement.
-
-_CRX Architecture--`config/crx/crx.h'_
-
- `b'
- Registers from r0 to r14 (registers without stack pointer)
-
- `l'
- Register r16 (64-bit accumulator lo register)
-
- `h'
- Register r17 (64-bit accumulator hi register)
-
- `k'
- Register pair r16-r17. (64-bit accumulator lo-hi pair)
-
- `I'
- Constant that fits in 3 bits
-
- `J'
- Constant that fits in 4 bits
-
- `K'
- Constant that fits in 5 bits
-
- `L'
- Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
-
- `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/rs6000.h'_
-
- `b'
- Address base register
-
- `f'
- Floating point register
-
- `v'
- Vector register
-
- `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'
- `FPMEM' stack memory for FPR-GPR transfers
-
- `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
-
- `Q'
- Memory operand that is an offset from a register (`m' is
- preferable for `asm' statements)
-
- `Z'
- Memory operand that is an indexed or indirect from a register
- (`m' is preferable for `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
-
-
-_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, as a pair (for instructions that
- return half the result in one and half in the other).
-
- `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. Remember that `m' allows postincrement and
- postdecrement which require printing with `%Pn' on IA-64.
- Use `S' to disallow postincrement and postdecrement.
-
- `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
-
-_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
-
-_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.
-
-_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
-
-
-_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_
-
- `a'
- Register `a'
-
- `b'
- Register `b'
-
- `d'
- Register `d'
-
- `q'
- An 8-bit register
-
- `t'
- Temporary soft register _.tmp
-
- `u'
- A soft register _.d1 to _.d31
-
- `w'
- Stack pointer register
-
- `x'
- Register `x'
-
- `y'
- Register `y'
-
- `z'
- Pseudo register `z' (replaced by `x' or `y' at the end)
-
- `A'
- An address register: x, y or z
-
- `B'
- An address register: x or y
-
- `D'
- Register pair (x:d) to form a 32-bit value
-
- `L'
- Constants in the range -65536 to 65535
-
- `M'
- Constants whose 16-bit low part is zero
-
- `N'
- Constant integer 1 or -1
-
- `O'
- Constant integer 16
-
- `P'
- Constants in the range -8 to 2
-
-
-_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.
-
- `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
-
- `M'
- A constant in the range supported by `movrcc' instructions
-
- `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
-
- `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
-
- `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.
-
-
-_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
-
-
-
-\1f
-File: gccint.info, Node: Disable Insn Alternatives, Next: Machine Constraints, Prev: Modifiers, 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)))
-
-\1f
-File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, 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 a `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.
-
-\1f
-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)))]
-
- "")
-
-\1f
-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 `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_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_extract_evenM'
- Extract even elements from the input vectors (operand 1 and
- operand 2). The even elements of operand 2 are concatenated to
- the even elements of operand 1 in their original order. The result
- is stored in operand 0. The output and input vectors should have
- the same modes.
-
-`vec_extract_oddM'
- Extract odd elements from the input vectors (operand 1 and operand
- 2). The odd elements of operand 2 are concatenated to the odd
- elements of operand 1 in their original order. The result is
- stored in operand 0. The output and input vectors should have the
- same modes.
-
-`vec_interleave_highM'
- Merge high elements of the two input vectors into the output
- vector. The output and input vectors should have the same modes
- (`N' elements). The high `N/2' elements of the first input vector
- are interleaved with the high `N/2' elements of the second input
- vector.
-
-`vec_interleave_lowM'
- Merge low elements of the two input vectors into the output
- vector. The output and input vectors should have the same modes
- (`N' elements). The low `N/2' elements of the first input vector
- are interleaved with the low `N/2' elements of the second input
- vector.
-
-`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.
-
-`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.
-
-`ssaddM3', `usaddM3'
-
-`subM3', `sssubM3', `ussubM3'
-
-`mulM3', `ssmulM3', `usmulM3'
-`divM3', `ssdivM3'
-`udivM3', `usdivM3'
-`modM3', `umodM3'
-`uminM3', `umaxM3'
-`andM3', `iorM3', `xorM3'
- Similar, for other arithmetic operations.
-
-`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'
- 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 elements of the two vectors, and put the N/2
- products 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.
-
-`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'.
-
-`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).
-
-`lroundM2'
- 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).
-
-`lfloorM2'
- 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).
-
-`lceilM2'
- 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.
-
-`cmpM'
- Compare operand 0 and operand 1, and set the condition codes. The
- RTL pattern should look like this:
-
- (set (cc0) (compare (match_operand:M 0 ...)
- (match_operand:M 1 ...)))
-
-`tstM'
- Compare operand 0 against zero, and set the condition codes. The
- RTL pattern should look like this:
-
- (set (cc0) (match_operand:M 0 ...))
-
- `tstM' patterns should not be defined for machines that do not use
- `(cc0)'. Doing so would confuse the optimizer since it would no
- longer be clear which `set' operations were comparisons. The
- `cmpM' patterns should be used instead.
-
-`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 `word_mode' for M. However, if you can
- generate better code knowing the range of valid lengths is smaller
- than those representable in a full word, 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 `word_mode'.
-
- 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.
-
-`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)'.
-
- 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 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 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. 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.
-
-`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.
-
-`extzv'
- Like `extv' except that the bit-field value is zero-extended.
-
-`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.
-
-`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
- true, operand 2 is moved into operand 0, otherwise (operand 2 +
- operand 3) is moved.
-
-`sCOND'
- Store zero or nonzero in the operand according to the condition
- codes. Value stored is nonzero iff the condition COND is true.
- COND is the name of a comparison operation expression code, such
- as `eq', `lt' or `leu'.
-
- You specify the mode that the operand 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 `sCOND' patterns, you
- should omit those operations from the machine description.
-
- 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 omit these patterns.
-
- If these operations are omitted, the compiler will usually
- generate code that copies the constant one to the target and
- branches around an assignment of zero to the target. If this code
- is more efficient than the potential instructions used for the
- `sCOND' pattern followed by those required to convert the result
- into a 1 or a zero in `SImode', you should omit the `sCOND'
- operations from the machine description.
-
-`bCOND'
- Conditional branch instruction. Operand 0 is a `label_ref' that
- refers to the label to jump to. Jump if the condition codes meet
- condition COND.
-
- Some machines do not follow the model assumed here where a
- comparison instruction is followed by a conditional branch
- instruction. In that case, the `cmpM' (and `tstM') patterns should
- simply store the operands away and generate all the required insns
- in a `define_expand' (*note Expander Definitions::) for the
- conditional branch operations. All calls to expand `bCOND'
- patterns are immediately preceded by calls to expand either a
- `cmpM' pattern or a `tstM' pattern.
-
- Machines that use a pseudo register for the condition code value,
- or where the mode used for the comparison depends on the condition
- being tested, should also use the above mechanism. *Note Jump
- Patterns::.
-
- The above discussion also applies to the `movMODEcc' and `sCOND'
- patterns.
-
-`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.
-
- 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 a `addr_vec' or `addr_diff_vec' inside of a
- `jump_insn'. 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. This instruction takes five
- operands: Operand 0 is the register to decrement and test; operand
- 1 is the number of loop iterations as a `const_int' or
- `const0_rtx' if this cannot be determined until run-time; operand
- 2 is the actual or estimated maximum number of iterations as a
- `const_int'; operand 3 is the number of enclosed loops as a
- `const_int' (an innermost loop has a value of 1); operand 4 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. If nested
- low-overhead looping is not supported, use a `define_expand'
- (*note Expander Definitions::) and make the pattern fail if
- operand 3 is not `const1_rtx'. Similarly, if the actual or
- estimated maximum number of iterations is too large for this
- instruction, make it fail.
-
-`doloop_begin'
- Companion instruction to `doloop_end' required for machines that
- need to perform some initialization, such as loading special
- registers used by a low-overhead looping instruction. 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 cannot be done on your system by probing the
- stack with a load or store instruction (*note Stack Checking::),
- define this pattern to perform the needed check and signaling an
- error if the stack has overflowed. The single operand is the
- location in the stack furthest from the current stack pointer that
- you need to validate. Normally, on machines where this pattern is
- needed, you would obtain the stack limit from a global or
- thread-specific variable or register.
-
-`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 an
- 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 transfered
- 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.
-
-`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.
-
-`conditional_trap'
- Conditional trap instruction. Operand 0 is a piece of RTL which
- performs a comparison. Operand 1 is the trap code, an integer.
-
- A typical `conditional_trap' pattern looks like
-
- (define_insn "conditional_trap"
- [(trap_if (match_operator 0 "trap_operator"
- [(cc0) (const_int 0)])
- (match_operand 1 "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 from moving instructions across the boundary defined by
- the blockage insn. Normally an UNSPEC_VOLATILE pattern.
-
-`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.
-
-`sync_compare_and_swap_ccMODE'
- This pattern is just like `sync_compare_and_swapMODE', except it
- should act as if compare part of the compare-and-swap were issued
- via `cmpM'. This comparison will only be used with `EQ' and `NE'
- branches and `setcc' operations.
-
- Some targets do expose the success or failure of the
- compare-and-swap operation via the status flags. Ideally we
- wouldn't need a separate named pattern in order to take advantage
- of this, but the combine pass does not handle patterns with
- multiple sets, which is required by definition for
- `sync_compare_and_swapMODE'.
-
-`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 are 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.
-
-`stack_protect_set'
- This pattern, if defined, moves a `Pmode' 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 `Pmode' 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 weren't 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.
-
-
-\1f
-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.
-
-\1f
-File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
-
-16.11 Interdependence of Patterns
-=================================
-
-Every machine description must have a named pattern for each of the
-conditional branch names `bCOND'. The recognition template must always
-have the form
-
- (set (pc)
- (if_then_else (COND (cc0) (const_int 0))
- (label_ref (match_operand 0 "" ""))
- (pc)))
-
-In addition, every machine description must have an anonymous pattern
-for each of the possible reverse-conditional branches. Their templates
-look like
-
- (set (pc)
- (if_then_else (COND (cc0) (const_int 0))
- (pc)
- (label_ref (match_operand 0 "" ""))))
-
-They are necessary because jump optimization can turn direct-conditional
-branches into reverse-conditional branches.
-
- It is often convenient to use the `match_operator' construct to reduce
-the number of patterns that must be specified for branches. For
-example,
-
- (define_insn ""
- [(set (pc)
- (if_then_else (match_operator 0 "comparison_operator"
- [(cc0) (const_int 0)])
- (pc)
- (label_ref (match_operand 1 "" ""))))]
- "CONDITION"
- "...")
-
- 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.
-
-\1f
-File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
-
-16.12 Defining Jump Instruction Patterns
-========================================
-
-For most machines, GCC assumes that the machine has a condition code.
-A comparison insn sets the condition code, recording the results of both
-signed and unsigned comparison of the given operands. A separate branch
-insn tests the condition code and branches or not according its value.
-The branch insns come in distinct signed and unsigned flavors. Many
-common machines, such as the VAX, the 68000 and the 32000, work this
-way.
-
- Some machines have distinct signed and unsigned compare instructions,
-and only one set of conditional branch instructions. The easiest way
-to handle these machines is to treat them just like the others until
-the final stage where assembly code is written. At this time, when
-outputting code for the compare instruction, peek ahead at the
-following branch using `next_cc0_user (insn)'. (The variable `insn'
-refers to the insn being output, in the output-writing code in an
-instruction pattern.) If the RTL says that is an unsigned branch,
-output an unsigned compare; otherwise output a signed compare. When
-the branch itself is output, you can treat signed and unsigned branches
-identically.
-
- The reason you can do this is that GCC always generates a pair of
-consecutive RTL insns, possibly separated by `note' insns, one to set
-the condition code and one to test it, and keeps the pair inviolate
-until the end.
-
- To go with this technique, you must define the machine-description
-macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
-compare instruction is superfluous.
-
- Some machines have compare-and-branch instructions and no condition
-code. A similar technique works for them. When it is time to "output"
-a compare instruction, record its operands in two static variables.
-When outputting the branch-on-condition-code instruction that follows,
-actually output a compare-and-branch instruction that uses the
-remembered operands.
-
- It also works to define patterns for compare-and-branch instructions.
-In optimizing compilation, the pair of compare and branch instructions
-will be combined according to these patterns. But this does not happen
-if optimization is not requested. So you must use one of the solutions
-above in addition to any special patterns you define.
-
- In many RISC machines, most instructions do not affect the condition
-code and there may not even be a separate condition code register. On
-these machines, the restriction that the definition and use of the
-condition code be adjacent insns is not necessary and can prevent
-important optimizations. 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.
-
- On these machines, do not use `(cc0)', but instead use a register to
-represent the condition code. 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.
-
- On some machines, the type of branch instruction generated may depend
-on the way the condition code was produced; for example, on the 68k and
-SPARC, setting the condition code directly from an add or subtract
-instruction does not clear the overflow bit the way that a test
-instruction does, so a different branch instruction must be used for
-some conditional branches. For machines that use `(cc0)', the set and
-use of the condition code must be adjacent (separated only by `note'
-insns) allowing flags in `cc_status' to be used. (*Note Condition
-Code::.) Also, the comparison and branch insns can be located from
-each other by using the functions `prev_cc0_setter' and `next_cc0_user'.
-
- However, this is not true on machines that do not use `(cc0)'. On
-those machines, no assumptions can be made about the adjacency of the
-compare and branch insns and the above methods cannot be used. Instead,
-we use the machine mode of the condition code register to record
-different formats of the condition code register.
-
- Registers used to store the condition code value should have a mode
-that is in class `MODE_CC'. Normally, it will be `CCmode'. If
-additional modes are required (as for the add example mentioned above in
-the SPARC), define them in `MACHINE-modes.def' (*note Condition
-Code::). Also define `SELECT_CC_MODE' to choose a mode given an
-operand of a compare.
-
- If it is known during RTL generation that a different mode will be
-required (for example, if the machine has separate compare instructions
-for signed and unsigned quantities, like most IBM processors), they can
-be specified at that time.
-
- If the cases that require different modes would be made by instruction
-combination, the macro `SELECT_CC_MODE' determines which machine mode
-should be used for the comparison result. The patterns should be
-written using that mode. 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)))]
- ""
- "...")
-
- The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for
-comparisons whose argument is a `plus'.
-
-\1f
-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.
-
-\1f
-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 A) B) C)' is
- canonicalized as `(minus A (mult B C))'.
-
- * For the `compare' operator, a constant is always the second operand
- on machines where `cc0' is used (*note Jump Patterns::). On other
- machines, there are rare cases where the compiler might want to
- construct a `compare' with a constant as the first operand.
- However, these cases are not common enough for it to be worthwhile
- to provide a pattern matching a constant as the first operand
- unless the machine actually has such an instruction.
-
- 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)
-
- * On machines that do not use `cc0', `(compare X (const_int 0))'
- will be converted to X.
-
- * 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.
-
-
- Further canonicalization rules are defined in the function
-`commutative_operand_precedence' in `gcc/rtlanal.c'.
-
-\1f
-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.
-
- 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.
-
-\1f
-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 an 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.
-
-\1f
-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.
-
-\1f
-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
-
-\1f
-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)))])
- ...]
- ...)
-
-\1f
-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'.
-
-\1f
-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.
-* Delay Slots:: Defining delay slots required for a machine.
-* Processor pipeline description:: Specifying information for insn scheduling.
-
-\1f
-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.
-
- 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
- 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::.
-
-
-\1f
-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.
-
-`(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. Test the flags `very_likely', `likely',
- `very_unlikely', and `unlikely' to determine if a conditional
- branch is expected to be taken.
-
- If the `very_likely' flag is true, then the `likely' flag is also
- true. Likewise for the `very_unlikely' and `unlikely' flags.
-
- 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.
-
- The `very_likely' and `likely' flags are true if the `insn' being
- scheduled is not a conditional branch. The `very_unlikely' and
- `unlikely' flags are false if the `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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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)))])
-
-\1f
-File: gccint.info, Node: Constant Attributes, Next: Delay Slots, 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.
-
-\1f
-File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes
-
-16.19.7 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)])
-
-\1f
-File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes
-
-16.19.8 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. The instructions in the string are separated by
-commas.
-
- 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).
-
- 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.
-
- * "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.
-
- * "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.
-
-\1f
-File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, 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")
-
- 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'.
-
- When `define_cond_exec' is used, an implicit reference to the
-`predicable' instruction attribute is made. *Note Insn Attributes::.
-This attribute must be boolean (i.e. have exactly two elements in its
-LIST-OF-VALUES). Further, it must not be used with complex
-expressions. That is, the default and all uses in the insns must be a
-simple constant, not dependent on the alternative or anything else.
-
- 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")
-
-\1f
-File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Conditional Execution, Up: Machine Desc
-
-16.21 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.
-
-\1f
-File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc
-
-16.22 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.
-
-\1f
-File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators
-
-16.22.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
-
-\1f
-File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators
-
-16.22.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::.
-
-\1f
-File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators
-
-16.22.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.
-
-\1f
-File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators
-
-16.22.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")])
-
-\1f
-File: gccint.info, Node: Code Iterators, Prev: Mode Iterators, Up: Iterators
-
-16.22.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;
- })
-
- ...
-
-\1f
-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.
-* Misc:: Everything else.
-
-\1f
-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.
-
-\1f
-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: SWITCH_TAKES_ARG (CHAR)
- A C expression which determines whether the option `-CHAR' takes
- arguments. The value should be the number of arguments that
- option takes-zero, for many options.
-
- By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
- which handles the standard options properly. You need not define
- `SWITCH_TAKES_ARG' unless you wish to add additional options which
- take arguments. Any redefinition should call
- `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
-
- -- Macro: WORD_SWITCH_TAKES_ARG (NAME)
- A C expression which determines whether the option `-NAME' takes
- arguments. The value should be the number of arguments that
- option takes-zero, for many options. This macro rather than
- `SWITCH_TAKES_ARG' is used for multi-character option names.
-
- By default, this macro is defined as
- `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
- properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
- wish to add additional options which take arguments. Any
- redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
- check for additional options.
-
- -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR)
- A C expression which determines whether the option `-CHAR' stops
- compilation before the generation of an executable. The value is
- boolean, nonzero if the option does stop an executable from being
- generated, zero otherwise.
-
- By default, this macro is defined as
- `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
- options properly. You need not define
- `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
- options which affect the generation of an executable. Any
- redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
- then check for additional options.
-
- -- Macro: SWITCHES_NEED_SPACES
- A string-valued C expression which enumerates the options for which
- the linker needs a space between the option and its argument.
-
- If this macro is not defined, the default value is `""'.
-
- -- Macro: TARGET_OPTION_TRANSLATE_TABLE
- If defined, a list of pairs of strings, the first of which is a
- potential command line target to the `gcc' driver program, and the
- second of which is a space-separated (tabs and other whitespace
- are not supported) list of options with which to replace the first
- option. The target defining this list is responsible for assuring
- that the results are valid. Replacement options may not be the
- `--opt' style, they must be the `-opt' style. It is the intention
- of this macro to provide a mechanism for substitution that affects
- the multilibs chosen, such as one option that enables many
- options, some of which select multilibs. Example nonsensical
- definition, where `-malt-abi', `-EB', and `-mspoo' cause different
- multilibs to be chosen:
-
- #define TARGET_OPTION_TRANSLATE_TABLE \
- { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \
- { "-compat", "-EB -malign=4 -mspoo" }
-
- -- 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 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.
-
- -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
- A nonzero value causes `collect2' to remove duplicate
- `-LDIRECTORY' search directories from linking commands. Do not
- give it a nonzero value if removing duplicate search directories
- changes the linker's semantics.
-
- -- 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
- `-b' option is used, or 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
- `-b' option is used, or 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 `-b' option is
- used, or 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 `SYSTEM_INCLUDE_DIR' in the search order.
-
- Cross compilers do not search either `/usr/local/include' or its
- replacement.
-
- -- Macro: MODIFY_TARGET_NAME
- Define this macro if you wish to define command-line switches that
- modify the default target name.
-
- For each switch, you can include a string to be appended to the
- first part of the configuration name or a string to be deleted
- from the configuration name, if present. The definition should be
- an initializer for an array of structures. Each array element
- should have three elements: the switch name (a string constant,
- including the initial dash), one of the enumeration codes `ADD' or
- `DELETE' to indicate whether the string should be inserted or
- deleted, and the string to be inserted or deleted (a string
- constant).
-
- For example, on a machine where `64' at the end of the
- configuration name denotes a 64-bit target and you want the `-32'
- and `-64' switches to select between 32- and 64-bit targets, you
- would code
-
- #define MODIFY_TARGET_NAME \
- { { "-32", DELETE, "64"}, \
- {"-64", ADD, "64"}}
-
- -- Macro: SYSTEM_INCLUDE_DIR
- Define this macro as a C string constant if you wish to specify a
- system-specific directory to search for header files before the
- standard directory. `SYSTEM_INCLUDE_DIR' comes before
- `STANDARD_INCLUDE_DIR' in the search order.
-
- Cross compilers do not use this macro and do not search the
- directory specified.
-
- -- Macro: STANDARD_INCLUDE_DIR
- Define this macro as a C string constant if you wish to override
- the standard choice of `/usr/include' as the default prefix to try
- when searching for header files.
-
- Cross compilers ignore this macro and do not search either
- `/usr/include' or its replacement.
-
- -- Macro: STANDARD_INCLUDE_COMPONENT
- The "component" corresponding to `STANDARD_INCLUDE_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', `SYSTEM_INCLUDE_DIR',
- `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_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/'.
-
-\1f
-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.
-
- -- Variable: Target Hook int TARGET_DEFAULT_TARGET_FLAGS
- This variable specifies the initial value of `target_flags'. Its
- default setting is 0.
-
- -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char
- *ARG, int VALUE)
- 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.
-
- CODE specifies the `OPT_NAME' enumeration value associated with
- the selected option; NAME is just a rendering of the option name
- in which non-alphanumeric characters are replaced by underscores.
- ARG specifies the string argument and is null if no argument was
- given. If the option is flagged as a `UInteger' (*note Option
- properties::), VALUE is the numeric value of the argument.
- Otherwise VALUE is 1 if the positive form of the option was used
- and 0 if the "no-" form was.
-
- -- 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 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.
-
- -- Macro: TARGET_VERSION
- This macro is a C statement to print on `stderr' a string
- describing the particular machine description choice. Every
- machine description should define `TARGET_VERSION'. For example:
-
- #ifdef MOTOROLA
- #define TARGET_VERSION \
- fprintf (stderr, " (68k, Motorola syntax)");
- #else
- #define TARGET_VERSION \
- fprintf (stderr, " (68k, MIT syntax)");
- #endif
-
- -- Macro: OVERRIDE_OPTIONS
- Sometimes certain combinations of command options do not make
- sense on a particular target machine. You can define a macro
- `OVERRIDE_OPTIONS' to take account of this. This macro, if
- defined, is executed once just after all the command options have
- been parsed.
-
- Don't use this macro to turn on various extra optimizations for
- `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
-
- -- Macro: C_COMMON_OVERRIDE_OPTIONS
- This is similar to `OVERRIDE_OPTIONS' 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.
-
- -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE)
- Some machines may desire to change what optimizations are
- performed for various optimization levels. This macro, if
- defined, is executed once just after the optimization level is
- determined and before the remainder of the command options have
- been parsed. Values set in this macro are used as the default
- values for the other command line options.
-
- LEVEL is the optimization level specified; 2 if `-O2' is
- specified, 1 if `-O' is specified, and 0 if neither is specified.
-
- SIZE is nonzero if `-Os' is specified and zero otherwise.
-
- This macro is run once at program startup and when the optimization
- options are changed via `#pragma GCC optimize' or by using the
- `optimize' attribute.
-
- *Do not examine `write_symbols' in this macro!* The debugging
- options are not supposed to alter the generated code.
-
- -- Target Hook: bool TARGET_HELP (void)
- This hook is called in response to the user invoking
- `--target-help' on the command line. It gives the target a chance
- to display extra information on the target specific command line
- options found in its `.opt' file.
-
- -- Macro: CAN_DEBUG_WITHOUT_FP
- Define this macro if debugging can be performed even without a
- frame pointer. If this macro is defined, GCC will turn on the
- `-fomit-frame-pointer' option whenever `-O' is specified.
-
-\1f
-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 `ggc_alloc', including the structure itself.
-
-\1f
-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; GCC fundamentally assumes
- that the order of words in memory is the same as the order in
- registers. This macro need not be a constant.
-
- -- Macro: LIBGCC2_WORDS_BIG_ENDIAN
- Define this macro if `WORDS_BIG_ENDIAN' is not constant. This
- must be a constant value with the same meaning as
- `WORDS_BIG_ENDIAN', which will be used only when compiling
- `libgcc2.c'. Typically the value will be set based on
- preprocessor defines.
-
- -- 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_UNIT
- Define this macro to be the number of bits in an addressable
- storage unit (byte). If you do not define this macro the default
- is 8.
-
- -- 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: UNITS_PER_SIMD_WORD (MODE)
- Number of units in the vectors that the vectorizer can produce for
- scalar mode MODE. The default is equal to `UNITS_PER_WORD',
- because the vectorizer can do some transformations even in absence
- of specialized SIMD hardware.
-
- -- 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.
-
- -- Macro: PROMOTE_FUNCTION_MODE
- Like `PROMOTE_MODE', but is applied to outgoing function arguments
- or function return values, as specified by
- `TARGET_PROMOTE_FUNCTION_ARGS' and
- `TARGET_PROMOTE_FUNCTION_RETURN', respectively.
-
- The default is `PROMOTE_MODE'.
-
- -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE)
- This target hook should return `true' if the promotion described by
- `PROMOTE_FUNCTION_MODE' should be done for outgoing function
- arguments.
-
- -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE)
- This target hook should return `true' if the promotion described by
- `PROMOTE_FUNCTION_MODE' should be done for the return value of
- functions.
-
- If this target hook returns `true', `TARGET_FUNCTION_VALUE' must
- perform the same promotions done by `PROMOTE_FUNCTION_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: 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.
-
- -- 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.
-
- -- 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.
-
- -- 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 `!TARGET_STRICT_ALIGN'.
-
- -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
- Return 1 if a structure 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 ()
- 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 ()
- 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.
-
- -- 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_VECTOR_OPAQUE_P (tree TYPE)
- This target hook should return `true' a vector is opaque. That
- is, if no cast is needed when copying a vector value of type TYPE
- into another vector lvalue of the same size. Vector opaque types
- cannot be initialized. The default is that there are no such
- types.
-
- -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (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 (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.
-
-\1f
-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 `LIBGCC2_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 `LIBGCC2_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: 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 `LIBGCC2_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
- `init_decl_processing' in the file `c-decl.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: 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: 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.
-
-\1f
-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.
-
-\1f
-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.
-
- -- Macro: CONDITIONAL_REGISTER_USAGE
- Zero or more C statements that 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.
-
- You need not define this macro if it has no work to do.
-
- 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.
-
-\1f
-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: ORDER_REGS_FOR_LOCAL_ALLOC
- 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: 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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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: 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.
-
-\1f
-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 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.
-
- 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, OUTER_CODE, INDEX_CODE)
- A C expression whose value is the register class to which a valid
- base register 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. It may be either
- a suitable hard register or a pseudo register that has been
- allocated such a hard register.
-
- -- 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, OUTER_CODE,
- INDEX_CODE)
- A C expression that is just like `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.
-
- -- 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
- `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
- using `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).
-
- -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
- Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
- input reloads. If you don't define this macro, the default is to
- use CLASS, unchanged.
-
- You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage
- reload from using some alternatives, like `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: enum reg_class TARGET_SECONDARY_RELOAD (bool IN_P, rtx
- X, enum reg_class 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 that 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.
-
- -- Macro: SMALL_REGISTER_CLASSES
- 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.
-
- Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero
- value on these machines. When this macro has a nonzero value, the
- compiler will try to minimize the lifetime of hard registers.
-
- It is always safe to define this macro 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 macro with a nonzero value when it is required, the
- compiler will run out of spill registers and print a fatal error
- message. For most machines, you should not define this macro at
- all.
-
- -- Macro: CLASS_LIKELY_SPILLED_P (CLASS)
- A C expression whose value is nonzero if pseudos that have been
- assigned to registers of class CLASS would likely be spilled
- because registers of CLASS are needed for spill registers.
-
- The default value of this macro returns 1 if CLASS has exactly one
- register and zero otherwise. On most machines, this default
- should be used. Only define this macro to some other expression
- if pseudos allocated by `local-alloc.c' end up in memory because
- their hard registers were needed for spill registers. If this
- macro returns nonzero for those classes, those pseudos will only
- be allocated by `global.c', which knows how to reallocate the
- pseudo to another register. If there would not be another
- register available for reallocation, you should not change the
- definition of this macro since the only effect of such a
- definition would be to slow down register allocation.
-
- -- 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: const enum reg_class * TARGET_IRA_COVER_CLASSES ()
- Return an array of cover classes for the Integrated Register
- Allocator (IRA). Cover classes are a set of non-intersecting
- register classes covering all hard registers used for register
- allocation purposes. If a move between two registers in the same
- cover class is possible, it should be cheaper than a load or store
- of the registers. The array is terminated by a `LIM_REG_CLASSES'
- element.
-
- This hook is called once at compiler startup, after the
- command-line options have been processed. It is then re-examined
- by every call to `target_reinit'.
-
- The default implementation returns `IRA_COVER_CLASSES', if defined,
- otherwise there is no default implementation. You must define
- either this macro or `IRA_COVER_CLASSES' in order to use the
- integrated register allocator with Chaitin-Briggs coloring. If the
- macro is not defined, the only available coloring algorithm is
- Chow's priority coloring.
-
- -- Macro: IRA_COVER_CLASSES
- See the documentation for `TARGET_IRA_COVER_CLASSES'.
-
-\1f
-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 a `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.
-
-\1f
-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::
-
-\1f
-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: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
- 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)',
- 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.
-
-\1f
-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_UNWIND_SUPPORT
- A string specifying a file to be #include'd in unwind-dw2.c. The
- file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'.
-
- -- 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 `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'.
-
-\1f
-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 require 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
- An integer representing the interval at which GCC must generate
- stack probe instructions. You will normally define this macro to
- be no larger than the size of the "guard pages" at the end of a
- stack area. The default value of 4096 is suitable for most
- systems.
-
- -- Macro: STACK_CHECK_PROBE_LOAD
- An integer which is nonzero if GCC should perform the stack probe
- as a load instruction and zero if GCC should use a store
- instruction. The default is zero, which is the most efficient
- choice on most systems.
-
- -- 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 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.
-
-\1f
-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: 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 next two macros should be defined.
-
- -- Macro: STATIC_CHAIN
- -- Macro: STATIC_CHAIN_INCOMING
- If the static chain is passed in memory, these macros provide rtx
- giving `mem' expressions that denote where they are stored.
- `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
- seen by the calling and called functions, respectively. Often the
- former will be at an offset from the stack pointer and the latter
- at an offset from the frame pointer.
-
- The variables `stack_pointer_rtx', `frame_pointer_rtx', and
- `arg_pointer_rtx' will have been initialized prior to the use of
- these macros and should be used to refer to those items.
-
- If the static chain is passed in a register, the two previous
- macros should be defined instead.
-
- -- 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'.
-
-
-\1f
-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.
-
- -- Macro: FRAME_POINTER_REQUIRED
- A C expression which is nonzero if a function must have and use a
- frame pointer. This expression is evaluated in the reload pass.
- If its value is nonzero the function will have a frame pointer.
-
- The expression can in principle examine the current function and
- decide according to the facts, but on most machines the constant 0
- or the constant 1 suffices. Use 0 when the machine allows code to
- be generated with no frame pointer, and doing so saves some time
- or space. Use 1 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 `FRAME_POINTER_REQUIRED' says. 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.
-
- -- 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
- `FRAME_POINTER_REQUIRED' is defined to always be 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.
-
- -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG)
- A C expression that returns nonzero if the compiler is allowed to
- try to replace register number FROM-REG with register number
- TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
- defined, and will usually be the constant 1, since most of the
- cases preventing register elimination are things that the compiler
- already knows about.
-
- -- 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.
-
-\1f
-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 (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)
-
- -- Macro: ACCUMULATE_OUTGOING_ARGS
- A C expression. If nonzero, the maximum amount of space required
- for outgoing arguments will be computed and placed into the
- variable `current_function_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
- `current_function_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.
-
- -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)
- A C expression that should indicate 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.
-
- STACK-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 STACK-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.
-
-\1f
-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.
-
- -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
- A C expression that controls whether a function argument is passed
- in a register, and which register.
-
- The arguments are CUM, 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 1 for an ordinary argument and 0 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 value of the expression 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.
-
- For machines like the VAX and 68000, where normally all arguments
- are pushed, zero suffices as a definition.
-
- 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 macro 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 `FUNCTION_ARG' return 0 whenever NAMED is 0.
-
- 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 `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, 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.
-
- -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
- Define this macro 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, `FUNCTION_ARG' computes the register in which
- the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
- defined in a similar fashion to tell the function being called
- where the arguments will arrive.
-
- If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
- both purposes.
-
- -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *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.
-
- `FUNCTION_ARG' for these arguments should return the first
- register to be used by the caller for this argument; likewise
- `FUNCTION_INCOMING_ARG', for the called function.
-
- -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM,
- enum machine_mode MODE, 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 *CUM, enum
- machine_mode MODE, 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 `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'.
-
- -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
- A C statement (sans semicolon) to update the summarizer variable
- CUM 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 `FUNCTION_ARG', etc.
-
- This macro 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 always just enough to reach the next
- multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
- it.
-
- 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.
-
- -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE)
- If defined, a C expression that gives the alignment boundary, in
- bits, of an argument with the specified mode and type. If it is
- not defined, `PARM_BOUNDARY' is used for all arguments.
-
- -- 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 (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: 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, tree *PRE_P, tree *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_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.
-
-\1f
-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 (tree RET_TYPE, 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 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 `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: FUNCTION_OUTGOING_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.
-
- -- 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.
-
- -- Macro: TARGET_ENUM_VA_LIST (IDX, PNAME, PTYPE)
- This target macro 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 PTYPE a pointer to a `tree' typed variable.
- The arguments PNAME and PTYPE 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.
-
- -- 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 (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.
-
-\1f
-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 (tree TYPE, 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.
-
-\1f
-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.
-
-\1f
-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 variable that is called
- `current_function_pops_args' is the number of bytes of its
- arguments that a function should pop. *Note Scalar Return::.
-
- * A region of `current_function_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
- `current_function_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.
-
- -- Macro: DELAY_SLOTS_FOR_EPILOGUE
- Define this macro if the function epilogue contains delay slots to
- which instructions from the rest of the function can be "moved".
- The definition should be a C expression whose value is an integer
- representing the number of delay slots there.
-
- -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
- A C expression that returns 1 if INSN can be placed in delay slot
- number N of the epilogue.
-
- The argument N is an integer which identifies the delay slot now
- being considered (since different slots may have different rules of
- eligibility). It is never negative and is always less than the
- number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
- returns). If you reject a particular insn for a given delay slot,
- in principle, it may be reconsidered for a subsequent delay slot.
- Also, other insns may (at least in principle) be considered for
- the so far unfilled delay slot.
-
- The insns accepted to fill the epilogue delay slots are put in an
- RTL list made with `insn_list' objects, stored in the variable
- `current_function_epilogue_delay_list'. The insn for the first
- delay slot comes first in the list. Your definition of the macro
- `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
- outputting the insns in this list, usually by calling
- `final_scan_insn'.
-
- You need not define this macro if you did not define
- `DELAY_SLOTS_FOR_EPILOGUE'.
-
- -- 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 (tree
- THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
- VCALL_OFFSET, 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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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 tree expression 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'.
-
-\1f
-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_args_info (CATEGORY)
- Use this built-in function to find the first anonymous arguments in
- registers.
-
- In general, a machine may have several categories of registers
- used for arguments, each for a particular category of data types.
- (For example, on some machines, floating-point registers are used
- for floating-point arguments while other arguments are passed in
- the general registers.) To make non-varargs functions use the
- proper calling convention, you have defined the `CUMULATIVE_ARGS'
- data type to record how many registers in each category have been
- used so far
-
- `__builtin_args_info' accesses the same data structure of type
- `CUMULATIVE_ARGS' after the ordinary argument layout is finished
- with it, with CATEGORY specifying which word to access. Thus, the
- value indicates the first unused register in a given category.
-
- Normally, you would use `__builtin_args_info' in the implementation
- of `va_start', accessing each category just once and storing the
- value in the `va_list' object. This is because `va_list' will
- have to update the values, and there is no way to alter the values
- accessed by `__builtin_args_info'.
-
- -- Macro: __builtin_next_arg (LASTARG)
- This is the equivalent of `__builtin_args_info', for stack
- arguments. It 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
- *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
- *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 `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 zero.
-
- -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
- 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.
-
-\1f
-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.
-
- -- Macro: TRAMPOLINE_TEMPLATE (FILE)
- A C statement to output, on the stream FILE, 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 macro, it means no template is needed
- for the target. Do not define this macro 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 `BIGGEST_ALIGNMENT'
- is used for aligning trampolines.
-
- -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)
- A C statement to initialize the variable parts of a trampoline.
- ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
- for the address of the nested function; STATIC_CHAIN is an RTX for
- the static chain value that should be passed to the function when
- it is called.
-
- -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR)
- A C statement that should perform any machine-specific adjustment
- in the address of the trampoline. Its argument contains the
- address that was passed to `INITIALIZE_TRAMPOLINE'. In case the
- address to be used for a function call should be different from
- the address in which the template was stored, the different
- address should be assigned to ADDR. If this macro is not defined,
- ADDR will be used for function calls.
-
- If this macro is not defined, by default the trampoline is
- allocated as a stack slot. This default is right for most
- machines. The exceptions are machines where it is impossible to
- execute instructions in the stack area. On such machines, you may
- have to implement a separate stack, using this macro in
- conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and
- `TARGET_ASM_FUNCTION_EPILOGUE'.
-
- FP points to a data structure, a `struct function', which
- describes the compilation status of the immediate containing
- function of the function which the trampoline is for. The stack
- slot for the trampoline is in the stack frame of this containing
- function. Other allocation strategies probably must do something
- analogous with this information.
-
- 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.
-
- The operating system may also require the stack to be made executable
-before calling the trampoline. To implement this requirement, define
-the following macro.
-
- -- Macro: ENABLE_EXECUTE_STACK
- Define this macro if certain operations must be performed before
- executing code located on the stack. The macro should expand to a
- series of C file-scope constructs (e.g. functions) and provide a
- unique entry point named `__enable_execute_stack'. The target is
- responsible for emitting calls to the entry point in the code, for
- example from the `INITIALIZE_TRAMPOLINE' macro.
-
- 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.
-
-\1f
-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.
-
- -- 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: US_SOFTWARE_GOFAST
- Define this macro if your system C library uses the US Software
- GOFAST library to provide floating point emulation.
-
- In addition to defining this macro, your architecture must set
- `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else
- call that function from its version of that hook. It is defined
- in `config/gofast.h', which must be included by your
- architecture's `CPU.c' file. See `sparc/sparc.c' for an example.
-
- If this macro is defined, the
- `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return
- false for `SFmode' and `DFmode' comparisons.
-
- -- 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.
-
- -- Macro: TARGET_C99_FUNCTIONS
- When this macro is nonzero, GCC will implicitly optimize `sin'
- calls into `sinf' and similarly for other functions defined by C99
- standard. The default is zero because a number of existing
- systems lack support for these functions in their runtime so this
- macro needs to be redefined to one on systems that do support the
- C99 runtime.
-
- -- Macro: TARGET_HAS_SINCOS
- When this macro is nonzero, GCC will implicitly optimize calls to
- `sin' and `cos' with the same argument to a call to `sincos'. The
- default is zero. The target has to provide the following
- functions:
- void sincos(double x, double *sin, double *cos);
- void sincosf(float x, float *sin, float *cos);
- void sincosl(long double x, long double *sin, long double *cos);
-
- -- Macro: NEXT_OBJC_RUNTIME
- Define this macro to generate code for Objective-C message sending
- using the calling convention of the NeXT system. This calling
- convention involves passing the object, the selector and the
- method arguments all at once to the method-lookup library function.
-
- The default calling convention passes just the object and the
- selector to the lookup function, which returns a pointer to the
- method.
-
-\1f
-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, this can be defined as
- `CONSTANT_P (X)', but a few machines are more restrictive in 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 `GO_IF_LEGITIMATE_ADDRESS'
- would ever accept.
-
- -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
- A C compound statement with a conditional `goto LABEL;' executed
- if X (an RTX) is a legitimate memory address on the target machine
- for a memory operand of mode MODE.
-
- It usually pays to define several simpler macros to serve as
- subroutines for this one. Otherwise it may be too complicated to
- understand.
-
- This macro must exist in two variants: a strict variant and a
- non-strict one. 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. In
- contexts where some kind of register is required, a pseudo-register
- with no hard register must be rejected.
-
- 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.
-
- 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.
-
- Subroutines to check for acceptable registers for various purposes
- (one for base registers, one for index registers, and so on) are
- typically among the subroutines used to define
- `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
- need have two variants; the higher levels of macros may be the
- same whether strict or not.
-
- 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::.
-
- -- 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
- `GO_IF_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.
-
- -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)
- A C compound statement that attempts to replace X with a valid
- memory address for an operand of mode MODE. WIN will be a C
- statement label elsewhere in the code; the macro definition may use
-
- GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
-
- to avoid further processing if the address has become legitimate.
-
- 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 generated by this macro should 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.
-
- It is not necessary for this macro to come up with a legitimate
- address. The compiler has standard ways of doing so in all cases.
- In fact, it is safe to omit this macro. 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.
-
- -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
- A C statement or compound statement with a conditional `goto
- LABEL;' executed if memory address X (an RTX) 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.
-
- -- Macro: LEGITIMATE_CONSTANT_P (X)
- A C expression that is nonzero if X is a legitimate constant for
- an immediate operand on the target machine. You can assume that X
- satisfies `CONSTANT_P', so you need not check this. In fact, `1'
- is a suitable definition for this macro on machines where anything
- `CONSTANT_P' is valid.
-
- -- 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_CANNOT_FORCE_CONST_MEM (rtx X)
- This hook should return true if X is of a form that cannot (or
- should not) be spilled to the constant pool. 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, 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: tree TARGET_BUILTIN_RECIPROCAL (enum tree_code FN,
- bool TM_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. TM_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: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree X)
- This hook should return the DECL of a function F that implements
- widening multiplication of the even elements of two input vectors
- of type X.
-
- If this hook is defined, the autovectorizer will use it along with
- the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD' target hook when
- vectorizing widening multiplication in cases that the order of the
- results does not have to be preserved (e.g. used only by a
- reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
- will be used.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD (tree X)
- This hook should return the DECL of a function F that implements
- widening multiplication of the odd elements of two input vectors
- of type X.
-
- If this hook is defined, the autovectorizer will use it along with
- the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN' target hook when
- vectorizing widening multiplication in cases that the order of the
- results does not have to be preserved (e.g. used only by a
- reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
- will be used.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (enum
- tree_code CODE, tree TYPE)
- This hook should return the DECL of a function that implements
- conversion of the input vector of type TYPE. If TYPE is an
- integral type, the result of the conversion is a vector of
- floating-point type of the same size. If TYPE is a floating-point
- type, the result of the conversion is a vector of integral type of
- the same size. CODE 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
- (enum built_in_function CODE, 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
- return type of the vectorized function shall be of vector type
- VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
-
-\1f
-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.
-
- -- Variable: 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.
-
- -- Variable: 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 (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.
-
-\1f
-File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros
-
-17.16 Condition Code Status
-===========================
-
-This describes the condition code status.
-
- 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'.
-
- -- Macro: SELECT_CC_MODE (OP, X, Y)
- Returns a mode from class `MODE_CC' to be used when comparison
- operation code OP is applied to rtx X and Y. For example, on the
- SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::
- for a description of the reason for this definition)
-
- #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))
-
- You should define this macro if and only if you define extra CC
- modes in `MACHINE-modes.def'.
-
- -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1)
- 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, define this macro to be a C statement 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. You should modify CODE, OP0, and OP1 as required.
-
- 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 define this macro 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))
-
- -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2)
- A C expression that returns true if the conditional execution
- predicate OP1, a comparison operation, is the inverse of OP2 and
- vice versa. Define this to return 0 if the target has conditional
- execution predicates that cannot be reversed safely. There is no
- need to validate that the arguments of op1 and op2 are the same,
- this is done separately. If no expansion is specified, this macro
- is defined as follows:
-
- #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
- (GET_CODE ((x)) == reversed_comparison_code ((y), NULL))
-
- -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *,
- unsigned int *)
- 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 the second argument
- 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, enum machine_mode)
- 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'.
-
-\1f
-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.
-
- -- 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.
-
- -- 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 be
- returning value optimal for code size rather then performance
- considerations. PREDICTABLE_P is true for well predictable
- 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
- 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.
-
- 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
- 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.
-
- 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
- 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.
-
- 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: RANGE_TEST_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 *TOTAL)
- 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 rtx code of the expression
- in which it is contained, found in OUTER_CODE. CODE is the
- 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 `optimize_size' is
- nonzero, 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)
- 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.
-
-\1f
-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_READY, 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: 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: int 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: int 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_CYCLE_ADVANCE (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_CYCLE_ADVANCE (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)
- 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 passed as the parameter, the insn will be not chosen
- to be issued.
-
- The default is that any ready insns can be chosen to be issued.
-
- -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int,
- int, int *)
- This hook is called by the insn scheduler before issuing insn
- passed as the third parameter on given cycle. If the hook returns
- nonzero, the insn is not issued on given processors cycle.
- Instead of that, the processor cycle is advanced. If the value
- passed through the last parameter is zero, the insn ready queue is
- not sorted on the new cycle start as usually. The first parameter
- passes file for debugging output. The second one passes the
- scheduler verbose level of the debugging output. The forth and
- the fifth parameter values are correspondingly 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_def
- *_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, 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, make a copy of the
- current context in TC.
-
- -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
- Copy target scheduling context pointer 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: 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, make a copy of the
- current context in TC.
-
- -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
- Copy target scheduling context pointer 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, int
- REQUEST, 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: int TARGET_SCHED_NEEDS_BLOCK_P (rtx INSN)
- This hook is called by the insn scheduler during generation of
- recovery code for INSN. It should return nonzero, if the
- corresponding check instruction should branch to recovery code, or
- zero otherwise.
-
- -- Target Hook: rtx TARGET_SCHED_GEN_CHECK (rtx INSN, rtx LABEL, int
- MUTATE_P)
- 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: int
-TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (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 instruction that stand first in the
- ready list from being scheduled on the current cycle. For
- non-speculative instructions, the hook should always return
- nonzero. 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 (unsigned int
- *FLAGS, spec_info_t SPEC_INFO)
- This hook is used by the insn scheduler to find out what features
- should be enabled/used. FLAGS initially may have either the
- SCHED_RGN or SCHED_EBB bit set. This denotes the scheduler pass
- for which the data should be provided. The target backend should
- modify FLAGS by modifying the bits corresponding to the following
- features: USE_DEPS_LIST, USE_GLAT, DETACH_LIFE_INFO, and
- DO_SPECULATION. For the DO_SPECULATION feature an additional
- structure SPEC_INFO should be filled 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.
-
-\1f
-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
- neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are 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: 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: 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: 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: void 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 (tree EXP)
- Returns true if EXP should be placed into a "small data" section.
- The default version of this hook always returns false.
-
- -- Variable: 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_BINDS_LOCAL_P (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.
-
- -- Variable: Target Hook bool TARGET_HAVE_TLS
- Contains the value true if the target supports thread-local
- storage. The default value is false.
-
-\1f
-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 macros
-`GO_IF_LEGITIMATE_ADDRESS' and `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
- Define this macro if the register defined by
- `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. 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.
-
-\1f
-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.
-
-\1f
-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 ()
- 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 ()
- 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.
-
- -- 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.
-
- -- 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.
-
- -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING)
- A C statement to output something to the assembler file to handle a
- `#ident' directive containing the text STRING. If this macro is
- not defined, nothing is output for a `#ident' directive.
-
- -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
- unsigned int FLAGS, unsigned int ALIGN)
- 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 ALIGN is
- nonzero, it contains an alignment in bytes to be used for the
- section, otherwise some target default should be used. Only
- targets that must specify an alignment within the section
- directive need pay attention to ALIGN - we will still use
- `ASM_OUTPUT_ALIGN'.
-
- -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
- This flag is true if the target supports
- `TARGET_ASM_NAMED_SECTION'.
-
- -- 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.
-
-\1f
-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'.
-
- -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
- A C statement to recognize RTX patterns that `output_addr_const'
- can't deal with, and output assembly code to STREAM corresponding
- to the pattern X. This may be used to allow machine-dependent
- `UNSPEC's to appear within constants.
-
- If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must
- `goto fail', 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 complete normally.
-
- -- 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.
-
-\1f
-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.
-
- 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_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
- 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 ROUNDED is the size
- rounded up to whatever alignment the caller wants.
-
- Try to use function `asm_output_bss' defined in `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 either
- this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'.
- 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_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
- Like `ASM_OUTPUT_BSS' except takes the required alignment as a
- separate, explicit argument. If you define this macro, it is used
- in place of `ASM_OUTPUT_BSS', and gives you more flexibility in
- handling the required alignment of the variable. The alignment is
- specified as the number of bits.
-
- Try to use function `asm_output_aligned_bss' defined in file
- `varasm.c' when defining this macro.
-
- -- 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.
-
-\1f
-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_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: 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_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_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.
-
- -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for declaring the name NAME of a
- constant which is being defined. This macro is responsible for
- outputting the label definition (perhaps using
- `ASM_OUTPUT_LABEL'). The argument EXP is the value of the
- constant, and SIZE is the size of the constant in bytes. NAME
- will be an internal label.
-
- If this macro is not defined, then the 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' in the definition
- of this macro.
-
- -- 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 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. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is
- defined, the default definition is `1'; otherwise, it is `0'.
- 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, const
- char *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 (tree DECL)
- This target hook is a function to output to ASM_OUT_FILE an
- assembler directive to annotate used symbol. Darwin target use
- .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'.
-
- -- 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.
-
- -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM commands to declare that the label NAME is an Objective-C
- class reference. This is only needed for targets whose linkers
- have special support for NeXT-style runtimes.
-
- -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM commands to declare that the label NAME is an unresolved
- Objective-C class reference. This is only needed for targets
- whose linkers have special support for NeXT-style runtimes.
-
-\1f
-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.
-
-\1f
-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'.
-
- 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.
-
-\1f
-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: 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.
-
- -- 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 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.
-
-\1f
-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_insn' 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 (STREAM, DECL,
- FOR_EH, 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 (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_UNWIND_EMIT (FILE * STREAM, rtx INSN)
- This target hook emits and assembly directives required to unwind
- the given instruction. This is only used when TARGET_UNWIND_INFO
- is set.
-
-\1f
-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 either `UNALIGNED_INT_ASM_OP' or
- `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
-
- If `TARGET_UNWIND_INFO' is defined, the target specific unwinder
- will be used in all cases. Defining this macro will enable the
- generation of DWARF 2 frame debugging information.
-
- If `TARGET_UNWIND_INFO' is not defined, and this macro is defined
- to 1, the DWARF 2 unwinder will be the default exception handling
- mechanism; otherwise, the `setjmp'/`longjmp'-based scheme will be
- used by default.
-
- -- Macro: TARGET_UNWIND_INFO
- Define this macro if your target has ABI specified unwind tables.
- Usually these will be output by `TARGET_UNWIND_EMIT'.
-
- -- Variable: 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.
-
- -- Macro: MUST_USE_SJLJ_EXCEPTIONS
- This macro need only be defined if `DWARF2_UNWIND_INFO' is
- runtime-variable. In that case, `except.h' cannot correctly
- determine the corresponding definition of
- `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly.
-
- -- 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: 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.
-
- -- Variable: 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 hook 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'.
-
-\1f
-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
- `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
- selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation.
-
- -- 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.
-
- -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
- The maximum number of bytes to skip 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, which follows
- a `NOTE_INSN_LOOP_BEG' note.
-
- 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
- `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
- selection in `align_loops' in a `LOOP_ALIGN' implementation.
-
- -- Macro: LOOP_ALIGN_MAX_SKIP
- The maximum number of bytes to skip when applying `LOOP_ALIGN'.
- 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
- `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
- selection in `align_labels' in a `LABEL_ALIGN' implementation.
-
- -- Macro: LABEL_ALIGN_MAX_SKIP
- The maximum number of bytes to skip when applying `LABEL_ALIGN'.
- 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'.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-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.
-
-\1f
-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_LBRAC (STREAM, NAME)
- Define this macro to say how to output to STREAM the debugging
- information for the start of a scope level for variable names. The
- argument NAME is the name of an assembler symbol (for use with
- `assemble_name') whose value is the address where the scope begins.
-
- -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME)
- Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
-
- -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
- Define this macro if the target machine requires special handling
- to output an `N_FUN' entry for the function DECL.
-
- -- 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.
-
-\1f
-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 a `N_SO' stab with an empty string,
- whose value is the highest absolute text address in the file.
-
-\1f
-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 (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 `DWARF2_UNWIND_INFO' (*note
- Exception Region Output:: is nonzero, GCC will output this
- information not matter how you define `DWARF2_FRAME_INFO'.
-
- -- 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.
-
- -- 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_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.
-
- -- 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.
-
-\1f
-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 `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'.
-
-\1f
-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: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
- enum machine_mode X)
- Truncates the floating point value X to fit in MODE. The return
- value is still a full-size `REAL_VALUE_TYPE', but it has an
- appropriate bit pattern to be output as a floating constant whose
- precision accords with mode MODE.
-
- -- 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.
-
-\1f
-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 (MODE, INSN)
- 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.
-
-\1f
-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: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, 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 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 (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 (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_VALID_OPTION_ATTRIBUTE_P (tree FNDECL,
- tree NAME, tree ARGS, int FLAGS)
- This hook is called to parse the `attribute(option("..."))', and
- it allows the function to set different target machine compile time
- options for the current function that might be different than 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)
- This hook is called to save any additional target specific
- information in the STRUCT CL_TARGET_OPTION structure for function
- specific options. *Note Option file format::.
-
- -- Target Hook: void TARGET_OPTION_RESTORE (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.
-
- -- Target Hook: void TARGET_OPTION_PRINT (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 (target ARGS)
- This target hook parses the options for `#pragma GCC option' to
- set the machine specific options for functions that occur later in
- the input stream. The options should be the same as handled by the
- `TARGET_VALID_OPTION_ATTRIBUTE_P' hook.
-
- -- 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.
-
-\1f
-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.
-
-\1f
-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.
-
- -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES
- A comma-separated list (with leading comma) of pairs describing the
- alternate names of coprocessor registers. The format of each
- entry should be
- { ALTERNATENAME, REGISTER_NUMBER}
- Default: empty.
-
-\1f
-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 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'.
-
-\1f
-File: gccint.info, Node: C++ ABI, Next: Misc, 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 first byte should be used. A
- return value of `true' indicates 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).
-
-\1f
-File: gccint.info, Node: Misc, Prev: C++ ABI, Up: Target Macros
-
-17.30 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.
-
- -- Macro: CASE_VALUES_THRESHOLD
- Define this to be 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: CASE_USE_BIT_TESTS
- Define this macro to be a C expression to indicate whether C switch
- statements may be implemented by a sequence of bit tests. This is
- advantageous on processors that can efficiently implement left
- shift of 1 by the number of bits held in a register, but
- inappropriate on targets that would require a loop. By default,
- this macro returns `true' if the target defines an `ashlsi3'
- pattern, and `false' otherwise.
-
- -- 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.
-
- -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC
- Define this macro if the same instructions that convert a floating
- point number to a signed fixed point number also convert validly
- to an unsigned one.
-
- -- Target Hook: 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: 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
- MODE_REP so that MODE_REP 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 (`sCOND') when the condition is true. This
- description must apply to _all_ the `sCOND' 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 `sCOND' 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
- `sCOND' 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 Superoptizer 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.
-
- -- 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_SYSV_PRAGMA
- Define this macro (to a value of 1) if you want the System V style
- pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]'
- to be supported by gcc.
-
- The pack pragma specifies the maximum alignment (in bytes) of
- fields within a structure, in much the same way as the
- `__aligned__' and `__packed__' `__attribute__'s do. A pack value
- of zero resets the behavior to the default.
-
- A subtlety for Microsoft Visual C/C++ style bit-field packing
- (e.g. -mms-bitfields) for targets that support it: 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).
-
- 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.
-
- The weak pragma only works if `SUPPORTS_WEAK' and
- `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation
- of specifically named weak labels, optionally with a value.
-
- -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP
- Define this macro (to a value of 1) if you want to support the
- Win32 style pragmas `#pragma pack(push[,N])' and `#pragma
- pack(pop)'. The `pack(push,[N])' pragma specifies the maximum
- alignment (in bytes) of fields within a structure, in much the
- same way as the `__aligned__' and `__packed__' `__attribute__'s
- do. A pack value of zero resets the behavior to the default.
- Successive invocations of this pragma cause the previous values to
- be stacked, so that invocations of `#pragma pack(pop)' will return
- to the previous value.
-
- -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
- Define this macro, as well as `HANDLE_SYSV_PRAGMA', 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: 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: 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, or `""' if the target does not
- have a separate math library.
-
- You need only define this macro if the default of `"-lm"' 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_INIT_EXTRA_FIELDS (CE_INFO)
- A C expression to initialize any extra fields in a `struct
- ce_if_block' structure, which are defined by the
- `IFCVT_EXTRA_FIELDS' macro.
-
- -- Macro: IFCVT_EXTRA_FIELDS
- If defined, it should expand to a set of field declarations that
- will be added to the `struct ce_if_block' structure. These should
- be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro.
-
- -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG ()
- 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 ()
- 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' and `build_common_tree_nodes_2'; only
- language front ends that use those two functions will call
- `TARGET_INIT_BUILTINS'.
-
- -- 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 (tree FNDECL,
- tree 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'.
-
- -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST,
- 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. ARGLIST is the list of arguments passed to the
- built-in function. The result is another tree containing a
- simplified expression for the call's result. If IGNORE is true
- the value will be ignored.
-
- -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN)
- Take an instruction in INSN and return NULL if it is valid within a
- low-overhead loop, otherwise return a string 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.
-
- -- 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_COMMUTATIVE_P (rtx X, 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_leaf_function' in
- the hook, functions that use `REG_N_SETS', 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.
-
- -- 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: int 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.
-
- -- 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'.
-
- -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
- This target hook returns `true' if it is safe to use a local alias
- for a virtual function FNDECL when constructing thunks, `false'
- otherwise. By default, the hook 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
- (tree TYPELIST, tree FUNCDECL, 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 (tree FROMTYPE,
- 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, 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, tree
- TYPE1, 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.
-
- -- 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)
- Define this macro to an rtx for Dynamic Realign Argument Pointer
- if a different argument pointer register is needed to access the
- function's argument list when stack is aligned.
-
- -- 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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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"'.
-
- 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'.
-
-\1f
-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.
-
-\1f
-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'.
-
-`Floating Point Emulation'
- To have GCC include software floating point libraries in `libgcc.a'
- define `FPBIT' and `DPBIT' along with a few rules as follows:
- # We want fine grained libraries, so use the new code
- # to build the floating point emulation libraries.
- FPBIT = fp-bit.c
- DPBIT = dp-bit.c
-
-
- fp-bit.c: $(srcdir)/config/fp-bit.c
- echo '#define FLOAT' > fp-bit.c
- cat $(srcdir)/config/fp-bit.c >> fp-bit.c
-
- dp-bit.c: $(srcdir)/config/fp-bit.c
- cat $(srcdir)/config/fp-bit.c > dp-bit.c
-
- You may need to provide additional #defines at the beginning of
- `fp-bit.c' and `dp-bit.c' to control target endianness and other
- options.
-
-`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.
-
- 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_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.
-
-`NATIVE_SYSTEM_HEADER_DIR'
- If the default location for system headers is not `/usr/include',
- you must set this to the directory containing the headers. This
- value should match the value of the `SYSTEM_INCLUDE_DIR' macro.
-
-`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.
-
-\1f
-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.
-
-\1f
-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:
-
- * `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'.
-
-\1f
-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.
-
-\1f
-File: gccint.info, Node: Type Information, Next: Funding, 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' and `union'
-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 TAG GTY(())
- {
- FIELDS...
- };
-
- typedef struct TAG GTY(())
- {
- 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.
-
-* Menu:
-
-* GTY Options:: What goes inside a `GTY(())'.
-* GGC Roots:: Making global variables GGC roots.
-* Files:: How the generated files work.
-* Invoking the garbage collector:: How to invoke the garbage collector.
-
-\1f
-File: gccint.info, Node: GTY Options, Next: GGC Roots, 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. The first case is when a structure
- ends in a variable-length array, like this:
- struct rtvec_def GTY(()) {
- 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:
- tree *
- GTY ((length ("%h.regno_pointer_align_length"))) regno_decl;
- In this case, `regno_decl' has been allocated by writing something
- like
- x->regno_decl =
- ggc_alloc (x->regno_pointer_align_length * sizeof (tree));
- and the `length' provides the length of the field.
-
- This second use of `length' also works on global variables, like: static GTY((length ("reg_base_value_size")))
- rtx *reg_base_value;
-
-`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 tree_binding GTY(())
- {
- 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.
-
-`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.
-
-`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.
-
-\1f
-File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information
-
-22.2 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'.
-
-\1f
-File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information
-
-22.3 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'. For C, the file is `c-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.
-
-\1f
-File: gccint.info, Node: Invoking the garbage collector, Prev: Files, Up: Type Information
-
-22.4 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 it 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.
-
-\1f
-File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, 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.
-
-\1f
-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'
-
-\1f
-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'.
-
-\1f
-File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-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.
-
- * 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.
-
- * 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.
-
- * 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 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 port.
-
- * 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.
-
- * Zdenek Dvorak for a new loop unroller and various fixes.
-
- * 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
- continuously 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
- since the late 1980s.
-
- * 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 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.
-
- * 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.
-
- * 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.
-
- * 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.
-
- * 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 for GCC 3.x.
-
- * 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, etc.
-
- * 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.
-
- * 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 as well a serving as release manager for
- GCC 2.95.3.
-
- * 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.
-
- * 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.
-
- * 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'.
-
- * 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 his mips16 work, 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.
-
- * 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.
-
- * 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.
-
-\1f
-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.
-
-\0\b[index\0\b]
-* Menu:
-
-* msoft-float: Soft float library routines.
- (line 6)
-
-\1f
-File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top
-
-Concept Index
-*************
-
-\0\b[index\0\b]
-* Menu:
-
-* ! in constraint: Multi-Alternative. (line 47)
-* # in constraint: Modifiers. (line 67)
-* # in template: Output Template. (line 66)
-* #pragma: Misc. (line 381)
-* % in constraint: Modifiers. (line 45)
-* % in GTY option: GTY Options. (line 18)
-* % in template: Output Template. (line 6)
-* & in constraint: Modifiers. (line 25)
-* ( <1>: Sections. (line 160)
-* ( <2>: GIMPLE_CALL. (line 63)
-* ( <3>: GIMPLE_ASM. (line 21)
-* (: Logical Operators. (line 107)
-* (nil): RTL Objects. (line 73)
-* * <1>: Host Common. (line 17)
-* *: Scheduling. (line 246)
-* * in constraint: Modifiers. (line 72)
-* * in template: Output Statement. (line 29)
-* *gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54)
-* *gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60)
-* *gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67)
-* *gimple_call_arg_ptr: GIMPLE_CALL. (line 71)
-* *gimple_call_lhs_ptr: GIMPLE_CALL. (line 32)
-* *gimple_catch_types_ptr: GIMPLE_CATCH. (line 16)
-* *gimple_cdt_location_ptr: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 28)
-* *gimple_cdt_new_type_ptr: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 15)
-* *gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15)
-* *gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL.
- (line 16)
-* *gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23)
-* *gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54)
-* *gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64)
-* *gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34)
-* *gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44)
-* *gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL.
- (line 46)
-* *gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL.
- (line 34)
-* *gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL.
- (line 58)
-* *gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS.
- (line 33)
-* *gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS.
- (line 21)
-* *gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17)
-* *gimple_op_ptr: Manipulating GIMPLE statements.
- (line 84)
-* *gimple_ops <1>: Manipulating GIMPLE statements.
- (line 78)
-* *gimple_ops: Logical Operators. (line 82)
-* *gimple_phi_result_ptr: GIMPLE_PHI. (line 22)
-* *gsi_stmt_ptr: Sequence iterators. (line 80)
-* *TARGET_GET_PCH_VALIDITY: PCH Target. (line 7)
-* + in constraint: Modifiers. (line 12)
-* -fsection-anchors <1>: Anchored Addresses. (line 6)
-* -fsection-anchors: Special Accessors. (line 106)
-* /c in RTL dump: Flags. (line 234)
-* /f in RTL dump: Flags. (line 242)
-* /i in RTL dump: Flags. (line 294)
-* /j in RTL dump: Flags. (line 309)
-* /s in RTL dump: Flags. (line 258)
-* /u in RTL dump: Flags. (line 319)
-* /v in RTL dump: Flags. (line 351)
-* 0 in constraint: Simple Constraints. (line 120)
-* < in constraint: Simple Constraints. (line 48)
-* = in constraint: Modifiers. (line 8)
-* > in constraint: Simple Constraints. (line 52)
-* ? in constraint: Multi-Alternative. (line 41)
-* \: Output Template. (line 46)
-* __absvdi2: Integer library routines.
- (line 107)
-* __absvsi2: Integer library routines.
- (line 106)
-* __addda3: Fixed-point fractional library routines.
- (line 45)
-* __adddf3: Soft float library routines.
- (line 23)
-* __adddq3: Fixed-point fractional library routines.
- (line 33)
-* __addha3: Fixed-point fractional library routines.
- (line 43)
-* __addhq3: Fixed-point fractional library routines.
- (line 30)
-* __addqq3: Fixed-point fractional library routines.
- (line 29)
-* __addsa3: Fixed-point fractional library routines.
- (line 44)
-* __addsf3: Soft float library routines.
- (line 22)
-* __addsq3: Fixed-point fractional library routines.
- (line 31)
-* __addta3: Fixed-point fractional library routines.
- (line 47)
-* __addtf3: Soft float library routines.
- (line 25)
-* __adduda3: Fixed-point fractional library routines.
- (line 53)
-* __addudq3: Fixed-point fractional library routines.
- (line 41)
-* __adduha3: Fixed-point fractional library routines.
- (line 49)
-* __adduhq3: Fixed-point fractional library routines.
- (line 37)
-* __adduqq3: Fixed-point fractional library routines.
- (line 35)
-* __addusa3: Fixed-point fractional library routines.
- (line 51)
-* __addusq3: Fixed-point fractional library routines.
- (line 39)
-* __adduta3: Fixed-point fractional library routines.
- (line 55)
-* __addvdi3: Integer library routines.
- (line 111)
-* __addvsi3: Integer library routines.
- (line 110)
-* __addxf3: Soft float library routines.
- (line 27)
-* __ashlda3: Fixed-point fractional library routines.
- (line 351)
-* __ashldi3: Integer library routines.
- (line 14)
-* __ashldq3: Fixed-point fractional library routines.
- (line 340)
-* __ashlha3: Fixed-point fractional library routines.
- (line 349)
-* __ashlhq3: Fixed-point fractional library routines.
- (line 337)
-* __ashlqq3: Fixed-point fractional library routines.
- (line 336)
-* __ashlsa3: Fixed-point fractional library routines.
- (line 350)
-* __ashlsi3: Integer library routines.
- (line 13)
-* __ashlsq3: Fixed-point fractional library routines.
- (line 338)
-* __ashlta3: Fixed-point fractional library routines.
- (line 353)
-* __ashlti3: Integer library routines.
- (line 15)
-* __ashluda3: Fixed-point fractional library routines.
- (line 359)
-* __ashludq3: Fixed-point fractional library routines.
- (line 348)
-* __ashluha3: Fixed-point fractional library routines.
- (line 355)
-* __ashluhq3: Fixed-point fractional library routines.
- (line 344)
-* __ashluqq3: Fixed-point fractional library routines.
- (line 342)
-* __ashlusa3: Fixed-point fractional library routines.
- (line 357)
-* __ashlusq3: Fixed-point fractional library routines.
- (line 346)
-* __ashluta3: Fixed-point fractional library routines.
- (line 361)
-* __ashrda3: Fixed-point fractional library routines.
- (line 371)
-* __ashrdi3: Integer library routines.
- (line 19)
-* __ashrdq3: Fixed-point fractional library routines.
- (line 368)
-* __ashrha3: Fixed-point fractional library routines.
- (line 369)
-* __ashrhq3: Fixed-point fractional library routines.
- (line 365)
-* __ashrqq3: Fixed-point fractional library routines.
- (line 364)
-* __ashrsa3: Fixed-point fractional library routines.
- (line 370)
-* __ashrsi3: Integer library routines.
- (line 18)
-* __ashrsq3: Fixed-point fractional library routines.
- (line 366)
-* __ashrta3: Fixed-point fractional library routines.
- (line 373)
-* __ashrti3: Integer library routines.
- (line 20)
-* __bid_adddd3: Decimal float library routines.
- (line 25)
-* __bid_addsd3: Decimal float library routines.
- (line 21)
-* __bid_addtd3: Decimal float library routines.
- (line 29)
-* __bid_divdd3: Decimal float library routines.
- (line 68)
-* __bid_divsd3: Decimal float library routines.
- (line 64)
-* __bid_divtd3: Decimal float library routines.
- (line 72)
-* __bid_eqdd2: Decimal float library routines.
- (line 259)
-* __bid_eqsd2: Decimal float library routines.
- (line 257)
-* __bid_eqtd2: Decimal float library routines.
- (line 261)
-* __bid_extendddtd2: Decimal float library routines.
- (line 92)
-* __bid_extendddtf: Decimal float library routines.
- (line 140)
-* __bid_extendddxf: Decimal float library routines.
- (line 134)
-* __bid_extenddfdd: Decimal float library routines.
- (line 147)
-* __bid_extenddftd: Decimal float library routines.
- (line 107)
-* __bid_extendsddd2: Decimal float library routines.
- (line 88)
-* __bid_extendsddf: Decimal float library routines.
- (line 128)
-* __bid_extendsdtd2: Decimal float library routines.
- (line 90)
-* __bid_extendsdtf: Decimal float library routines.
- (line 138)
-* __bid_extendsdxf: Decimal float library routines.
- (line 132)
-* __bid_extendsfdd: Decimal float library routines.
- (line 103)
-* __bid_extendsfsd: Decimal float library routines.
- (line 145)
-* __bid_extendsftd: Decimal float library routines.
- (line 105)
-* __bid_extendtftd: Decimal float library routines.
- (line 149)
-* __bid_extendxftd: Decimal float library routines.
- (line 109)
-* __bid_fixdddi: Decimal float library routines.
- (line 170)
-* __bid_fixddsi: Decimal float library routines.
- (line 162)
-* __bid_fixsddi: Decimal float library routines.
- (line 168)
-* __bid_fixsdsi: Decimal float library routines.
- (line 160)
-* __bid_fixtddi: Decimal float library routines.
- (line 172)
-* __bid_fixtdsi: Decimal float library routines.
- (line 164)
-* __bid_fixunsdddi: Decimal float library routines.
- (line 187)
-* __bid_fixunsddsi: Decimal float library routines.
- (line 178)
-* __bid_fixunssddi: Decimal float library routines.
- (line 185)
-* __bid_fixunssdsi: Decimal float library routines.
- (line 176)
-* __bid_fixunstddi: Decimal float library routines.
- (line 189)
-* __bid_fixunstdsi: Decimal float library routines.
- (line 180)
-* __bid_floatdidd: Decimal float library routines.
- (line 205)
-* __bid_floatdisd: Decimal float library routines.
- (line 203)
-* __bid_floatditd: Decimal float library routines.
- (line 207)
-* __bid_floatsidd: Decimal float library routines.
- (line 196)
-* __bid_floatsisd: Decimal float library routines.
- (line 194)
-* __bid_floatsitd: Decimal float library routines.
- (line 198)
-* __bid_floatunsdidd: Decimal float library routines.
- (line 223)
-* __bid_floatunsdisd: Decimal float library routines.
- (line 221)
-* __bid_floatunsditd: Decimal float library routines.
- (line 225)
-* __bid_floatunssidd: Decimal float library routines.
- (line 214)
-* __bid_floatunssisd: Decimal float library routines.
- (line 212)
-* __bid_floatunssitd: Decimal float library routines.
- (line 216)
-* __bid_gedd2: Decimal float library routines.
- (line 277)
-* __bid_gesd2: Decimal float library routines.
- (line 275)
-* __bid_getd2: Decimal float library routines.
- (line 279)
-* __bid_gtdd2: Decimal float library routines.
- (line 304)
-* __bid_gtsd2: Decimal float library routines.
- (line 302)
-* __bid_gttd2: Decimal float library routines.
- (line 306)
-* __bid_ledd2: Decimal float library routines.
- (line 295)
-* __bid_lesd2: Decimal float library routines.
- (line 293)
-* __bid_letd2: Decimal float library routines.
- (line 297)
-* __bid_ltdd2: Decimal float library routines.
- (line 286)
-* __bid_ltsd2: Decimal float library routines.
- (line 284)
-* __bid_lttd2: Decimal float library routines.
- (line 288)
-* __bid_muldd3: Decimal float library routines.
- (line 54)
-* __bid_mulsd3: Decimal float library routines.
- (line 50)
-* __bid_multd3: Decimal float library routines.
- (line 58)
-* __bid_nedd2: Decimal float library routines.
- (line 268)
-* __bid_negdd2: Decimal float library routines.
- (line 78)
-* __bid_negsd2: Decimal float library routines.
- (line 76)
-* __bid_negtd2: Decimal float library routines.
- (line 80)
-* __bid_nesd2: Decimal float library routines.
- (line 266)
-* __bid_netd2: Decimal float library routines.
- (line 270)
-* __bid_subdd3: Decimal float library routines.
- (line 39)
-* __bid_subsd3: Decimal float library routines.
- (line 35)
-* __bid_subtd3: Decimal float library routines.
- (line 43)
-* __bid_truncdddf: Decimal float library routines.
- (line 153)
-* __bid_truncddsd2: Decimal float library routines.
- (line 94)
-* __bid_truncddsf: Decimal float library routines.
- (line 124)
-* __bid_truncdfsd: Decimal float library routines.
- (line 111)
-* __bid_truncsdsf: Decimal float library routines.
- (line 151)
-* __bid_trunctddd2: Decimal float library routines.
- (line 98)
-* __bid_trunctddf: Decimal float library routines.
- (line 130)
-* __bid_trunctdsd2: Decimal float library routines.
- (line 96)
-* __bid_trunctdsf: Decimal float library routines.
- (line 126)
-* __bid_trunctdtf: Decimal float library routines.
- (line 155)
-* __bid_trunctdxf: Decimal float library routines.
- (line 136)
-* __bid_trunctfdd: Decimal float library routines.
- (line 119)
-* __bid_trunctfsd: Decimal float library routines.
- (line 115)
-* __bid_truncxfdd: Decimal float library routines.
- (line 117)
-* __bid_truncxfsd: Decimal float library routines.
- (line 113)
-* __bid_unorddd2: Decimal float library routines.
- (line 235)
-* __bid_unordsd2: Decimal float library routines.
- (line 233)
-* __bid_unordtd2: Decimal float library routines.
- (line 237)
-* __bswapdi2: Integer library routines.
- (line 162)
-* __bswapsi2: Integer library routines.
- (line 161)
-* __builtin_args_info: Varargs. (line 42)
-* __builtin_classify_type: Varargs. (line 76)
-* __builtin_next_arg: Varargs. (line 66)
-* __builtin_saveregs: Varargs. (line 24)
-* __clear_cache: Miscellaneous routines.
- (line 10)
-* __clzdi2: Integer library routines.
- (line 131)
-* __clzsi2: Integer library routines.
- (line 130)
-* __clzti2: Integer library routines.
- (line 132)
-* __cmpda2: Fixed-point fractional library routines.
- (line 451)
-* __cmpdf2: Soft float library routines.
- (line 164)
-* __cmpdi2: Integer library routines.
- (line 87)
-* __cmpdq2: Fixed-point fractional library routines.
- (line 441)
-* __cmpha2: Fixed-point fractional library routines.
- (line 449)
-* __cmphq2: Fixed-point fractional library routines.
- (line 438)
-* __cmpqq2: Fixed-point fractional library routines.
- (line 437)
-* __cmpsa2: Fixed-point fractional library routines.
- (line 450)
-* __cmpsf2: Soft float library routines.
- (line 163)
-* __cmpsq2: Fixed-point fractional library routines.
- (line 439)
-* __cmpta2: Fixed-point fractional library routines.
- (line 453)
-* __cmptf2: Soft float library routines.
- (line 165)
-* __cmpti2: Integer library routines.
- (line 88)
-* __cmpuda2: Fixed-point fractional library routines.
- (line 458)
-* __cmpudq2: Fixed-point fractional library routines.
- (line 448)
-* __cmpuha2: Fixed-point fractional library routines.
- (line 455)
-* __cmpuhq2: Fixed-point fractional library routines.
- (line 444)
-* __cmpuqq2: Fixed-point fractional library routines.
- (line 443)
-* __cmpusa2: Fixed-point fractional library routines.
- (line 456)
-* __cmpusq2: Fixed-point fractional library routines.
- (line 446)
-* __cmputa2: Fixed-point fractional library routines.
- (line 460)
-* __CTOR_LIST__: Initialization. (line 25)
-* __ctzdi2: Integer library routines.
- (line 138)
-* __ctzsi2: Integer library routines.
- (line 137)
-* __ctzti2: Integer library routines.
- (line 139)
-* __divda3: Fixed-point fractional library routines.
- (line 227)
-* __divdc3: Soft float library routines.
- (line 252)
-* __divdf3: Soft float library routines.
- (line 48)
-* __divdi3: Integer library routines.
- (line 25)
-* __divdq3: Fixed-point fractional library routines.
- (line 223)
-* __divha3: Fixed-point fractional library routines.
- (line 225)
-* __divhq3: Fixed-point fractional library routines.
- (line 220)
-* __divqq3: Fixed-point fractional library routines.
- (line 219)
-* __divsa3: Fixed-point fractional library routines.
- (line 226)
-* __divsc3: Soft float library routines.
- (line 250)
-* __divsf3: Soft float library routines.
- (line 47)
-* __divsi3: Integer library routines.
- (line 24)
-* __divsq3: Fixed-point fractional library routines.
- (line 221)
-* __divta3: Fixed-point fractional library routines.
- (line 229)
-* __divtc3: Soft float library routines.
- (line 254)
-* __divtf3: Soft float library routines.
- (line 50)
-* __divti3: Integer library routines.
- (line 26)
-* __divxc3: Soft float library routines.
- (line 256)
-* __divxf3: Soft float library routines.
- (line 52)
-* __dpd_adddd3: Decimal float library routines.
- (line 23)
-* __dpd_addsd3: Decimal float library routines.
- (line 19)
-* __dpd_addtd3: Decimal float library routines.
- (line 27)
-* __dpd_divdd3: Decimal float library routines.
- (line 66)
-* __dpd_divsd3: Decimal float library routines.
- (line 62)
-* __dpd_divtd3: Decimal float library routines.
- (line 70)
-* __dpd_eqdd2: Decimal float library routines.
- (line 258)
-* __dpd_eqsd2: Decimal float library routines.
- (line 256)
-* __dpd_eqtd2: Decimal float library routines.
- (line 260)
-* __dpd_extendddtd2: Decimal float library routines.
- (line 91)
-* __dpd_extendddtf: Decimal float library routines.
- (line 139)
-* __dpd_extendddxf: Decimal float library routines.
- (line 133)
-* __dpd_extenddfdd: Decimal float library routines.
- (line 146)
-* __dpd_extenddftd: Decimal float library routines.
- (line 106)
-* __dpd_extendsddd2: Decimal float library routines.
- (line 87)
-* __dpd_extendsddf: Decimal float library routines.
- (line 127)
-* __dpd_extendsdtd2: Decimal float library routines.
- (line 89)
-* __dpd_extendsdtf: Decimal float library routines.
- (line 137)
-* __dpd_extendsdxf: Decimal float library routines.
- (line 131)
-* __dpd_extendsfdd: Decimal float library routines.
- (line 102)
-* __dpd_extendsfsd: Decimal float library routines.
- (line 144)
-* __dpd_extendsftd: Decimal float library routines.
- (line 104)
-* __dpd_extendtftd: Decimal float library routines.
- (line 148)
-* __dpd_extendxftd: Decimal float library routines.
- (line 108)
-* __dpd_fixdddi: Decimal float library routines.
- (line 169)
-* __dpd_fixddsi: Decimal float library routines.
- (line 161)
-* __dpd_fixsddi: Decimal float library routines.
- (line 167)
-* __dpd_fixsdsi: Decimal float library routines.
- (line 159)
-* __dpd_fixtddi: Decimal float library routines.
- (line 171)
-* __dpd_fixtdsi: Decimal float library routines.
- (line 163)
-* __dpd_fixunsdddi: Decimal float library routines.
- (line 186)
-* __dpd_fixunsddsi: Decimal float library routines.
- (line 177)
-* __dpd_fixunssddi: Decimal float library routines.
- (line 184)
-* __dpd_fixunssdsi: Decimal float library routines.
- (line 175)
-* __dpd_fixunstddi: Decimal float library routines.
- (line 188)
-* __dpd_fixunstdsi: Decimal float library routines.
- (line 179)
-* __dpd_floatdidd: Decimal float library routines.
- (line 204)
-* __dpd_floatdisd: Decimal float library routines.
- (line 202)
-* __dpd_floatditd: Decimal float library routines.
- (line 206)
-* __dpd_floatsidd: Decimal float library routines.
- (line 195)
-* __dpd_floatsisd: Decimal float library routines.
- (line 193)
-* __dpd_floatsitd: Decimal float library routines.
- (line 197)
-* __dpd_floatunsdidd: Decimal float library routines.
- (line 222)
-* __dpd_floatunsdisd: Decimal float library routines.
- (line 220)
-* __dpd_floatunsditd: Decimal float library routines.
- (line 224)
-* __dpd_floatunssidd: Decimal float library routines.
- (line 213)
-* __dpd_floatunssisd: Decimal float library routines.
- (line 211)
-* __dpd_floatunssitd: Decimal float library routines.
- (line 215)
-* __dpd_gedd2: Decimal float library routines.
- (line 276)
-* __dpd_gesd2: Decimal float library routines.
- (line 274)
-* __dpd_getd2: Decimal float library routines.
- (line 278)
-* __dpd_gtdd2: Decimal float library routines.
- (line 303)
-* __dpd_gtsd2: Decimal float library routines.
- (line 301)
-* __dpd_gttd2: Decimal float library routines.
- (line 305)
-* __dpd_ledd2: Decimal float library routines.
- (line 294)
-* __dpd_lesd2: Decimal float library routines.
- (line 292)
-* __dpd_letd2: Decimal float library routines.
- (line 296)
-* __dpd_ltdd2: Decimal float library routines.
- (line 285)
-* __dpd_ltsd2: Decimal float library routines.
- (line 283)
-* __dpd_lttd2: Decimal float library routines.
- (line 287)
-* __dpd_muldd3: Decimal float library routines.
- (line 52)
-* __dpd_mulsd3: Decimal float library routines.
- (line 48)
-* __dpd_multd3: Decimal float library routines.
- (line 56)
-* __dpd_nedd2: Decimal float library routines.
- (line 267)
-* __dpd_negdd2: Decimal float library routines.
- (line 77)
-* __dpd_negsd2: Decimal float library routines.
- (line 75)
-* __dpd_negtd2: Decimal float library routines.
- (line 79)
-* __dpd_nesd2: Decimal float library routines.
- (line 265)
-* __dpd_netd2: Decimal float library routines.
- (line 269)
-* __dpd_subdd3: Decimal float library routines.
- (line 37)
-* __dpd_subsd3: Decimal float library routines.
- (line 33)
-* __dpd_subtd3: Decimal float library routines.
- (line 41)
-* __dpd_truncdddf: Decimal float library routines.
- (line 152)
-* __dpd_truncddsd2: Decimal float library routines.
- (line 93)
-* __dpd_truncddsf: Decimal float library routines.
- (line 123)
-* __dpd_truncdfsd: Decimal float library routines.
- (line 110)
-* __dpd_truncsdsf: Decimal float library routines.
- (line 150)
-* __dpd_trunctddd2: Decimal float library routines.
- (line 97)
-* __dpd_trunctddf: Decimal float library routines.
- (line 129)
-* __dpd_trunctdsd2: Decimal float library routines.
- (line 95)
-* __dpd_trunctdsf: Decimal float library routines.
- (line 125)
-* __dpd_trunctdtf: Decimal float library routines.
- (line 154)
-* __dpd_trunctdxf: Decimal float library routines.
- (line 135)
-* __dpd_trunctfdd: Decimal float library routines.
- (line 118)
-* __dpd_trunctfsd: Decimal float library routines.
- (line 114)
-* __dpd_truncxfdd: Decimal float library routines.
- (line 116)
-* __dpd_truncxfsd: Decimal float library routines.
- (line 112)
-* __dpd_unorddd2: Decimal float library routines.
- (line 234)
-* __dpd_unordsd2: Decimal float library routines.
- (line 232)
-* __dpd_unordtd2: Decimal float library routines.
- (line 236)
-* __DTOR_LIST__: Initialization. (line 25)
-* __eqdf2: Soft float library routines.
- (line 194)
-* __eqsf2: Soft float library routines.
- (line 193)
-* __eqtf2: Soft float library routines.
- (line 195)
-* __extenddftf2: Soft float library routines.
- (line 68)
-* __extenddfxf2: Soft float library routines.
- (line 69)
-* __extendsfdf2: Soft float library routines.
- (line 65)
-* __extendsftf2: Soft float library routines.
- (line 66)
-* __extendsfxf2: Soft float library routines.
- (line 67)
-* __ffsdi2: Integer library routines.
- (line 144)
-* __ffsti2: Integer library routines.
- (line 145)
-* __fixdfdi: Soft float library routines.
- (line 88)
-* __fixdfsi: Soft float library routines.
- (line 81)
-* __fixdfti: Soft float library routines.
- (line 94)
-* __fixsfdi: Soft float library routines.
- (line 87)
-* __fixsfsi: Soft float library routines.
- (line 80)
-* __fixsfti: Soft float library routines.
- (line 93)
-* __fixtfdi: Soft float library routines.
- (line 89)
-* __fixtfsi: Soft float library routines.
- (line 82)
-* __fixtfti: Soft float library routines.
- (line 95)
-* __fixunsdfdi: Soft float library routines.
- (line 108)
-* __fixunsdfsi: Soft float library routines.
- (line 101)
-* __fixunsdfti: Soft float library routines.
- (line 115)
-* __fixunssfdi: Soft float library routines.
- (line 107)
-* __fixunssfsi: Soft float library routines.
- (line 100)
-* __fixunssfti: Soft float library routines.
- (line 114)
-* __fixunstfdi: Soft float library routines.
- (line 109)
-* __fixunstfsi: Soft float library routines.
- (line 102)
-* __fixunstfti: Soft float library routines.
- (line 116)
-* __fixunsxfdi: Soft float library routines.
- (line 110)
-* __fixunsxfsi: Soft float library routines.
- (line 103)
-* __fixunsxfti: Soft float library routines.
- (line 117)
-* __fixxfdi: Soft float library routines.
- (line 90)
-* __fixxfsi: Soft float library routines.
- (line 83)
-* __fixxfti: Soft float library routines.
- (line 96)
-* __floatdidf: Soft float library routines.
- (line 128)
-* __floatdisf: Soft float library routines.
- (line 127)
-* __floatditf: Soft float library routines.
- (line 129)
-* __floatdixf: Soft float library routines.
- (line 130)
-* __floatsidf: Soft float library routines.
- (line 122)
-* __floatsisf: Soft float library routines.
- (line 121)
-* __floatsitf: Soft float library routines.
- (line 123)
-* __floatsixf: Soft float library routines.
- (line 124)
-* __floattidf: Soft float library routines.
- (line 134)
-* __floattisf: Soft float library routines.
- (line 133)
-* __floattitf: Soft float library routines.
- (line 135)
-* __floattixf: Soft float library routines.
- (line 136)
-* __floatundidf: Soft float library routines.
- (line 146)
-* __floatundisf: Soft float library routines.
- (line 145)
-* __floatunditf: Soft float library routines.
- (line 147)
-* __floatundixf: Soft float library routines.
- (line 148)
-* __floatunsidf: Soft float library routines.
- (line 140)
-* __floatunsisf: Soft float library routines.
- (line 139)
-* __floatunsitf: Soft float library routines.
- (line 141)
-* __floatunsixf: Soft float library routines.
- (line 142)
-* __floatuntidf: Soft float library routines.
- (line 152)
-* __floatuntisf: Soft float library routines.
- (line 151)
-* __floatuntitf: Soft float library routines.
- (line 153)
-* __floatuntixf: Soft float library routines.
- (line 154)
-* __fractdadf: Fixed-point fractional library routines.
- (line 636)
-* __fractdadi: Fixed-point fractional library routines.
- (line 633)
-* __fractdadq: Fixed-point fractional library routines.
- (line 616)
-* __fractdaha2: Fixed-point fractional library routines.
- (line 617)
-* __fractdahi: Fixed-point fractional library routines.
- (line 631)
-* __fractdahq: Fixed-point fractional library routines.
- (line 614)
-* __fractdaqi: Fixed-point fractional library routines.
- (line 630)
-* __fractdaqq: Fixed-point fractional library routines.
- (line 613)
-* __fractdasa2: Fixed-point fractional library routines.
- (line 618)
-* __fractdasf: Fixed-point fractional library routines.
- (line 635)
-* __fractdasi: Fixed-point fractional library routines.
- (line 632)
-* __fractdasq: Fixed-point fractional library routines.
- (line 615)
-* __fractdata2: Fixed-point fractional library routines.
- (line 619)
-* __fractdati: Fixed-point fractional library routines.
- (line 634)
-* __fractdauda: Fixed-point fractional library routines.
- (line 627)
-* __fractdaudq: Fixed-point fractional library routines.
- (line 624)
-* __fractdauha: Fixed-point fractional library routines.
- (line 625)
-* __fractdauhq: Fixed-point fractional library routines.
- (line 621)
-* __fractdauqq: Fixed-point fractional library routines.
- (line 620)
-* __fractdausa: Fixed-point fractional library routines.
- (line 626)
-* __fractdausq: Fixed-point fractional library routines.
- (line 622)
-* __fractdauta: Fixed-point fractional library routines.
- (line 629)
-* __fractdfda: Fixed-point fractional library routines.
- (line 1025)
-* __fractdfdq: Fixed-point fractional library routines.
- (line 1022)
-* __fractdfha: Fixed-point fractional library routines.
- (line 1023)
-* __fractdfhq: Fixed-point fractional library routines.
- (line 1020)
-* __fractdfqq: Fixed-point fractional library routines.
- (line 1019)
-* __fractdfsa: Fixed-point fractional library routines.
- (line 1024)
-* __fractdfsq: Fixed-point fractional library routines.
- (line 1021)
-* __fractdfta: Fixed-point fractional library routines.
- (line 1026)
-* __fractdfuda: Fixed-point fractional library routines.
- (line 1033)
-* __fractdfudq: Fixed-point fractional library routines.
- (line 1030)
-* __fractdfuha: Fixed-point fractional library routines.
- (line 1031)
-* __fractdfuhq: Fixed-point fractional library routines.
- (line 1028)
-* __fractdfuqq: Fixed-point fractional library routines.
- (line 1027)
-* __fractdfusa: Fixed-point fractional library routines.
- (line 1032)
-* __fractdfusq: Fixed-point fractional library routines.
- (line 1029)
-* __fractdfuta: Fixed-point fractional library routines.
- (line 1034)
-* __fractdida: Fixed-point fractional library routines.
- (line 975)
-* __fractdidq: Fixed-point fractional library routines.
- (line 972)
-* __fractdiha: Fixed-point fractional library routines.
- (line 973)
-* __fractdihq: Fixed-point fractional library routines.
- (line 970)
-* __fractdiqq: Fixed-point fractional library routines.
- (line 969)
-* __fractdisa: Fixed-point fractional library routines.
- (line 974)
-* __fractdisq: Fixed-point fractional library routines.
- (line 971)
-* __fractdita: Fixed-point fractional library routines.
- (line 976)
-* __fractdiuda: Fixed-point fractional library routines.
- (line 983)
-* __fractdiudq: Fixed-point fractional library routines.
- (line 980)
-* __fractdiuha: Fixed-point fractional library routines.
- (line 981)
-* __fractdiuhq: Fixed-point fractional library routines.
- (line 978)
-* __fractdiuqq: Fixed-point fractional library routines.
- (line 977)
-* __fractdiusa: Fixed-point fractional library routines.
- (line 982)
-* __fractdiusq: Fixed-point fractional library routines.
- (line 979)
-* __fractdiuta: Fixed-point fractional library routines.
- (line 984)
-* __fractdqda: Fixed-point fractional library routines.
- (line 544)
-* __fractdqdf: Fixed-point fractional library routines.
- (line 566)
-* __fractdqdi: Fixed-point fractional library routines.
- (line 563)
-* __fractdqha: Fixed-point fractional library routines.
- (line 542)
-* __fractdqhi: Fixed-point fractional library routines.
- (line 561)
-* __fractdqhq2: Fixed-point fractional library routines.
- (line 540)
-* __fractdqqi: Fixed-point fractional library routines.
- (line 560)
-* __fractdqqq2: Fixed-point fractional library routines.
- (line 539)
-* __fractdqsa: Fixed-point fractional library routines.
- (line 543)
-* __fractdqsf: Fixed-point fractional library routines.
- (line 565)
-* __fractdqsi: Fixed-point fractional library routines.
- (line 562)
-* __fractdqsq2: Fixed-point fractional library routines.
- (line 541)
-* __fractdqta: Fixed-point fractional library routines.
- (line 545)
-* __fractdqti: Fixed-point fractional library routines.
- (line 564)
-* __fractdquda: Fixed-point fractional library routines.
- (line 557)
-* __fractdqudq: Fixed-point fractional library routines.
- (line 552)
-* __fractdquha: Fixed-point fractional library routines.
- (line 554)
-* __fractdquhq: Fixed-point fractional library routines.
- (line 548)
-* __fractdquqq: Fixed-point fractional library routines.
- (line 547)
-* __fractdqusa: Fixed-point fractional library routines.
- (line 555)
-* __fractdqusq: Fixed-point fractional library routines.
- (line 550)
-* __fractdquta: Fixed-point fractional library routines.
- (line 559)
-* __fracthada2: Fixed-point fractional library routines.
- (line 572)
-* __fracthadf: Fixed-point fractional library routines.
- (line 590)
-* __fracthadi: Fixed-point fractional library routines.
- (line 587)
-* __fracthadq: Fixed-point fractional library routines.
- (line 570)
-* __fracthahi: Fixed-point fractional library routines.
- (line 585)
-* __fracthahq: Fixed-point fractional library routines.
- (line 568)
-* __fracthaqi: Fixed-point fractional library routines.
- (line 584)
-* __fracthaqq: Fixed-point fractional library routines.
- (line 567)
-* __fracthasa2: Fixed-point fractional library routines.
- (line 571)
-* __fracthasf: Fixed-point fractional library routines.
- (line 589)
-* __fracthasi: Fixed-point fractional library routines.
- (line 586)
-* __fracthasq: Fixed-point fractional library routines.
- (line 569)
-* __fracthata2: Fixed-point fractional library routines.
- (line 573)
-* __fracthati: Fixed-point fractional library routines.
- (line 588)
-* __fracthauda: Fixed-point fractional library routines.
- (line 581)
-* __fracthaudq: Fixed-point fractional library routines.
- (line 578)
-* __fracthauha: Fixed-point fractional library routines.
- (line 579)
-* __fracthauhq: Fixed-point fractional library routines.
- (line 575)
-* __fracthauqq: Fixed-point fractional library routines.
- (line 574)
-* __fracthausa: Fixed-point fractional library routines.
- (line 580)
-* __fracthausq: Fixed-point fractional library routines.
- (line 576)
-* __fracthauta: Fixed-point fractional library routines.
- (line 583)
-* __fracthida: Fixed-point fractional library routines.
- (line 943)
-* __fracthidq: Fixed-point fractional library routines.
- (line 940)
-* __fracthiha: Fixed-point fractional library routines.
- (line 941)
-* __fracthihq: Fixed-point fractional library routines.
- (line 938)
-* __fracthiqq: Fixed-point fractional library routines.
- (line 937)
-* __fracthisa: Fixed-point fractional library routines.
- (line 942)
-* __fracthisq: Fixed-point fractional library routines.
- (line 939)
-* __fracthita: Fixed-point fractional library routines.
- (line 944)
-* __fracthiuda: Fixed-point fractional library routines.
- (line 951)
-* __fracthiudq: Fixed-point fractional library routines.
- (line 948)
-* __fracthiuha: Fixed-point fractional library routines.
- (line 949)
-* __fracthiuhq: Fixed-point fractional library routines.
- (line 946)
-* __fracthiuqq: Fixed-point fractional library routines.
- (line 945)
-* __fracthiusa: Fixed-point fractional library routines.
- (line 950)
-* __fracthiusq: Fixed-point fractional library routines.
- (line 947)
-* __fracthiuta: Fixed-point fractional library routines.
- (line 952)
-* __fracthqda: Fixed-point fractional library routines.
- (line 498)
-* __fracthqdf: Fixed-point fractional library routines.
- (line 514)
-* __fracthqdi: Fixed-point fractional library routines.
- (line 511)
-* __fracthqdq2: Fixed-point fractional library routines.
- (line 495)
-* __fracthqha: Fixed-point fractional library routines.
- (line 496)
-* __fracthqhi: Fixed-point fractional library routines.
- (line 509)
-* __fracthqqi: Fixed-point fractional library routines.
- (line 508)
-* __fracthqqq2: Fixed-point fractional library routines.
- (line 493)
-* __fracthqsa: Fixed-point fractional library routines.
- (line 497)
-* __fracthqsf: Fixed-point fractional library routines.
- (line 513)
-* __fracthqsi: Fixed-point fractional library routines.
- (line 510)
-* __fracthqsq2: Fixed-point fractional library routines.
- (line 494)
-* __fracthqta: Fixed-point fractional library routines.
- (line 499)
-* __fracthqti: Fixed-point fractional library routines.
- (line 512)
-* __fracthquda: Fixed-point fractional library routines.
- (line 506)
-* __fracthqudq: Fixed-point fractional library routines.
- (line 503)
-* __fracthquha: Fixed-point fractional library routines.
- (line 504)
-* __fracthquhq: Fixed-point fractional library routines.
- (line 501)
-* __fracthquqq: Fixed-point fractional library routines.
- (line 500)
-* __fracthqusa: Fixed-point fractional library routines.
- (line 505)
-* __fracthqusq: Fixed-point fractional library routines.
- (line 502)
-* __fracthquta: Fixed-point fractional library routines.
- (line 507)
-* __fractqida: Fixed-point fractional library routines.
- (line 925)
-* __fractqidq: Fixed-point fractional library routines.
- (line 922)
-* __fractqiha: Fixed-point fractional library routines.
- (line 923)
-* __fractqihq: Fixed-point fractional library routines.
- (line 920)
-* __fractqiqq: Fixed-point fractional library routines.
- (line 919)
-* __fractqisa: Fixed-point fractional library routines.
- (line 924)
-* __fractqisq: Fixed-point fractional library routines.
- (line 921)
-* __fractqita: Fixed-point fractional library routines.
- (line 926)
-* __fractqiuda: Fixed-point fractional library routines.
- (line 934)
-* __fractqiudq: Fixed-point fractional library routines.
- (line 931)
-* __fractqiuha: Fixed-point fractional library routines.
- (line 932)
-* __fractqiuhq: Fixed-point fractional library routines.
- (line 928)
-* __fractqiuqq: Fixed-point fractional library routines.
- (line 927)
-* __fractqiusa: Fixed-point fractional library routines.
- (line 933)
-* __fractqiusq: Fixed-point fractional library routines.
- (line 929)
-* __fractqiuta: Fixed-point fractional library routines.
- (line 936)
-* __fractqqda: Fixed-point fractional library routines.
- (line 474)
-* __fractqqdf: Fixed-point fractional library routines.
- (line 492)
-* __fractqqdi: Fixed-point fractional library routines.
- (line 489)
-* __fractqqdq2: Fixed-point fractional library routines.
- (line 471)
-* __fractqqha: Fixed-point fractional library routines.
- (line 472)
-* __fractqqhi: Fixed-point fractional library routines.
- (line 487)
-* __fractqqhq2: Fixed-point fractional library routines.
- (line 469)
-* __fractqqqi: Fixed-point fractional library routines.
- (line 486)
-* __fractqqsa: Fixed-point fractional library routines.
- (line 473)
-* __fractqqsf: Fixed-point fractional library routines.
- (line 491)
-* __fractqqsi: Fixed-point fractional library routines.
- (line 488)
-* __fractqqsq2: Fixed-point fractional library routines.
- (line 470)
-* __fractqqta: Fixed-point fractional library routines.
- (line 475)
-* __fractqqti: Fixed-point fractional library routines.
- (line 490)
-* __fractqquda: Fixed-point fractional library routines.
- (line 483)
-* __fractqqudq: Fixed-point fractional library routines.
- (line 480)
-* __fractqquha: Fixed-point fractional library routines.
- (line 481)
-* __fractqquhq: Fixed-point fractional library routines.
- (line 477)
-* __fractqquqq: Fixed-point fractional library routines.
- (line 476)
-* __fractqqusa: Fixed-point fractional library routines.
- (line 482)
-* __fractqqusq: Fixed-point fractional library routines.
- (line 478)
-* __fractqquta: Fixed-point fractional library routines.
- (line 485)
-* __fractsada2: Fixed-point fractional library routines.
- (line 596)
-* __fractsadf: Fixed-point fractional library routines.
- (line 612)
-* __fractsadi: Fixed-point fractional library routines.
- (line 609)
-* __fractsadq: Fixed-point fractional library routines.
- (line 594)
-* __fractsaha2: Fixed-point fractional library routines.
- (line 595)
-* __fractsahi: Fixed-point fractional library routines.
- (line 607)
-* __fractsahq: Fixed-point fractional library routines.
- (line 592)
-* __fractsaqi: Fixed-point fractional library routines.
- (line 606)
-* __fractsaqq: Fixed-point fractional library routines.
- (line 591)
-* __fractsasf: Fixed-point fractional library routines.
- (line 611)
-* __fractsasi: Fixed-point fractional library routines.
- (line 608)
-* __fractsasq: Fixed-point fractional library routines.
- (line 593)
-* __fractsata2: Fixed-point fractional library routines.
- (line 597)
-* __fractsati: Fixed-point fractional library routines.
- (line 610)
-* __fractsauda: Fixed-point fractional library routines.
- (line 604)
-* __fractsaudq: Fixed-point fractional library routines.
- (line 601)
-* __fractsauha: Fixed-point fractional library routines.
- (line 602)
-* __fractsauhq: Fixed-point fractional library routines.
- (line 599)
-* __fractsauqq: Fixed-point fractional library routines.
- (line 598)
-* __fractsausa: Fixed-point fractional library routines.
- (line 603)
-* __fractsausq: Fixed-point fractional library routines.
- (line 600)
-* __fractsauta: Fixed-point fractional library routines.
- (line 605)
-* __fractsfda: Fixed-point fractional library routines.
- (line 1009)
-* __fractsfdq: Fixed-point fractional library routines.
- (line 1006)
-* __fractsfha: Fixed-point fractional library routines.
- (line 1007)
-* __fractsfhq: Fixed-point fractional library routines.
- (line 1004)
-* __fractsfqq: Fixed-point fractional library routines.
- (line 1003)
-* __fractsfsa: Fixed-point fractional library routines.
- (line 1008)
-* __fractsfsq: Fixed-point fractional library routines.
- (line 1005)
-* __fractsfta: Fixed-point fractional library routines.
- (line 1010)
-* __fractsfuda: Fixed-point fractional library routines.
- (line 1017)
-* __fractsfudq: Fixed-point fractional library routines.
- (line 1014)
-* __fractsfuha: Fixed-point fractional library routines.
- (line 1015)
-* __fractsfuhq: Fixed-point fractional library routines.
- (line 1012)
-* __fractsfuqq: Fixed-point fractional library routines.
- (line 1011)
-* __fractsfusa: Fixed-point fractional library routines.
- (line 1016)
-* __fractsfusq: Fixed-point fractional library routines.
- (line 1013)
-* __fractsfuta: Fixed-point fractional library routines.
- (line 1018)
-* __fractsida: Fixed-point fractional library routines.
- (line 959)
-* __fractsidq: Fixed-point fractional library routines.
- (line 956)
-* __fractsiha: Fixed-point fractional library routines.
- (line 957)
-* __fractsihq: Fixed-point fractional library routines.
- (line 954)
-* __fractsiqq: Fixed-point fractional library routines.
- (line 953)
-* __fractsisa: Fixed-point fractional library routines.
- (line 958)
-* __fractsisq: Fixed-point fractional library routines.
- (line 955)
-* __fractsita: Fixed-point fractional library routines.
- (line 960)
-* __fractsiuda: Fixed-point fractional library routines.
- (line 967)
-* __fractsiudq: Fixed-point fractional library routines.
- (line 964)
-* __fractsiuha: Fixed-point fractional library routines.
- (line 965)
-* __fractsiuhq: Fixed-point fractional library routines.
- (line 962)
-* __fractsiuqq: Fixed-point fractional library routines.
- (line 961)
-* __fractsiusa: Fixed-point fractional library routines.
- (line 966)
-* __fractsiusq: Fixed-point fractional library routines.
- (line 963)
-* __fractsiuta: Fixed-point fractional library routines.
- (line 968)
-* __fractsqda: Fixed-point fractional library routines.
- (line 520)
-* __fractsqdf: Fixed-point fractional library routines.
- (line 538)
-* __fractsqdi: Fixed-point fractional library routines.
- (line 535)
-* __fractsqdq2: Fixed-point fractional library routines.
- (line 517)
-* __fractsqha: Fixed-point fractional library routines.
- (line 518)
-* __fractsqhi: Fixed-point fractional library routines.
- (line 533)
-* __fractsqhq2: Fixed-point fractional library routines.
- (line 516)
-* __fractsqqi: Fixed-point fractional library routines.
- (line 532)
-* __fractsqqq2: Fixed-point fractional library routines.
- (line 515)
-* __fractsqsa: Fixed-point fractional library routines.
- (line 519)
-* __fractsqsf: Fixed-point fractional library routines.
- (line 537)
-* __fractsqsi: Fixed-point fractional library routines.
- (line 534)
-* __fractsqta: Fixed-point fractional library routines.
- (line 521)
-* __fractsqti: Fixed-point fractional library routines.
- (line 536)
-* __fractsquda: Fixed-point fractional library routines.
- (line 529)
-* __fractsqudq: Fixed-point fractional library routines.
- (line 526)
-* __fractsquha: Fixed-point fractional library routines.
- (line 527)
-* __fractsquhq: Fixed-point fractional library routines.
- (line 523)
-* __fractsquqq: Fixed-point fractional library routines.
- (line 522)
-* __fractsqusa: Fixed-point fractional library routines.
- (line 528)
-* __fractsqusq: Fixed-point fractional library routines.
- (line 524)
-* __fractsquta: Fixed-point fractional library routines.
- (line 531)
-* __fracttada2: Fixed-point fractional library routines.
- (line 643)
-* __fracttadf: Fixed-point fractional library routines.
- (line 664)
-* __fracttadi: Fixed-point fractional library routines.
- (line 661)
-* __fracttadq: Fixed-point fractional library routines.
- (line 640)
-* __fracttaha2: Fixed-point fractional library routines.
- (line 641)
-* __fracttahi: Fixed-point fractional library routines.
- (line 659)
-* __fracttahq: Fixed-point fractional library routines.
- (line 638)
-* __fracttaqi: Fixed-point fractional library routines.
- (line 658)
-* __fracttaqq: Fixed-point fractional library routines.
- (line 637)
-* __fracttasa2: Fixed-point fractional library routines.
- (line 642)
-* __fracttasf: Fixed-point fractional library routines.
- (line 663)
-* __fracttasi: Fixed-point fractional library routines.
- (line 660)
-* __fracttasq: Fixed-point fractional library routines.
- (line 639)
-* __fracttati: Fixed-point fractional library routines.
- (line 662)
-* __fracttauda: Fixed-point fractional library routines.
- (line 655)
-* __fracttaudq: Fixed-point fractional library routines.
- (line 650)
-* __fracttauha: Fixed-point fractional library routines.
- (line 652)
-* __fracttauhq: Fixed-point fractional library routines.
- (line 646)
-* __fracttauqq: Fixed-point fractional library routines.
- (line 645)
-* __fracttausa: Fixed-point fractional library routines.
- (line 653)
-* __fracttausq: Fixed-point fractional library routines.
- (line 648)
-* __fracttauta: Fixed-point fractional library routines.
- (line 657)
-* __fracttida: Fixed-point fractional library routines.
- (line 991)
-* __fracttidq: Fixed-point fractional library routines.
- (line 988)
-* __fracttiha: Fixed-point fractional library routines.
- (line 989)
-* __fracttihq: Fixed-point fractional library routines.
- (line 986)
-* __fracttiqq: Fixed-point fractional library routines.
- (line 985)
-* __fracttisa: Fixed-point fractional library routines.
- (line 990)
-* __fracttisq: Fixed-point fractional library routines.
- (line 987)
-* __fracttita: Fixed-point fractional library routines.
- (line 992)
-* __fracttiuda: Fixed-point fractional library routines.
- (line 1000)
-* __fracttiudq: Fixed-point fractional library routines.
- (line 997)
-* __fracttiuha: Fixed-point fractional library routines.
- (line 998)
-* __fracttiuhq: Fixed-point fractional library routines.
- (line 994)
-* __fracttiuqq: Fixed-point fractional library routines.
- (line 993)
-* __fracttiusa: Fixed-point fractional library routines.
- (line 999)
-* __fracttiusq: Fixed-point fractional library routines.
- (line 995)
-* __fracttiuta: Fixed-point fractional library routines.
- (line 1002)
-* __fractudada: Fixed-point fractional library routines.
- (line 858)
-* __fractudadf: Fixed-point fractional library routines.
- (line 881)
-* __fractudadi: Fixed-point fractional library routines.
- (line 878)
-* __fractudadq: Fixed-point fractional library routines.
- (line 855)
-* __fractudaha: Fixed-point fractional library routines.
- (line 856)
-* __fractudahi: Fixed-point fractional library routines.
- (line 876)
-* __fractudahq: Fixed-point fractional library routines.
- (line 852)
-* __fractudaqi: Fixed-point fractional library routines.
- (line 875)
-* __fractudaqq: Fixed-point fractional library routines.
- (line 851)
-* __fractudasa: Fixed-point fractional library routines.
- (line 857)
-* __fractudasf: Fixed-point fractional library routines.
- (line 880)
-* __fractudasi: Fixed-point fractional library routines.
- (line 877)
-* __fractudasq: Fixed-point fractional library routines.
- (line 853)
-* __fractudata: Fixed-point fractional library routines.
- (line 860)
-* __fractudati: Fixed-point fractional library routines.
- (line 879)
-* __fractudaudq: Fixed-point fractional library routines.
- (line 868)
-* __fractudauha2: Fixed-point fractional library routines.
- (line 870)
-* __fractudauhq: Fixed-point fractional library routines.
- (line 864)
-* __fractudauqq: Fixed-point fractional library routines.
- (line 862)
-* __fractudausa2: Fixed-point fractional library routines.
- (line 872)
-* __fractudausq: Fixed-point fractional library routines.
- (line 866)
-* __fractudauta2: Fixed-point fractional library routines.
- (line 874)
-* __fractudqda: Fixed-point fractional library routines.
- (line 766)
-* __fractudqdf: Fixed-point fractional library routines.
- (line 791)
-* __fractudqdi: Fixed-point fractional library routines.
- (line 787)
-* __fractudqdq: Fixed-point fractional library routines.
- (line 761)
-* __fractudqha: Fixed-point fractional library routines.
- (line 763)
-* __fractudqhi: Fixed-point fractional library routines.
- (line 785)
-* __fractudqhq: Fixed-point fractional library routines.
- (line 757)
-* __fractudqqi: Fixed-point fractional library routines.
- (line 784)
-* __fractudqqq: Fixed-point fractional library routines.
- (line 756)
-* __fractudqsa: Fixed-point fractional library routines.
- (line 764)
-* __fractudqsf: Fixed-point fractional library routines.
- (line 790)
-* __fractudqsi: Fixed-point fractional library routines.
- (line 786)
-* __fractudqsq: Fixed-point fractional library routines.
- (line 759)
-* __fractudqta: Fixed-point fractional library routines.
- (line 768)
-* __fractudqti: Fixed-point fractional library routines.
- (line 789)
-* __fractudquda: Fixed-point fractional library routines.
- (line 780)
-* __fractudquha: Fixed-point fractional library routines.
- (line 776)
-* __fractudquhq2: Fixed-point fractional library routines.
- (line 772)
-* __fractudquqq2: Fixed-point fractional library routines.
- (line 770)
-* __fractudqusa: Fixed-point fractional library routines.
- (line 778)
-* __fractudqusq2: Fixed-point fractional library routines.
- (line 774)
-* __fractudquta: Fixed-point fractional library routines.
- (line 782)
-* __fractuhada: Fixed-point fractional library routines.
- (line 799)
-* __fractuhadf: Fixed-point fractional library routines.
- (line 822)
-* __fractuhadi: Fixed-point fractional library routines.
- (line 819)
-* __fractuhadq: Fixed-point fractional library routines.
- (line 796)
-* __fractuhaha: Fixed-point fractional library routines.
- (line 797)
-* __fractuhahi: Fixed-point fractional library routines.
- (line 817)
-* __fractuhahq: Fixed-point fractional library routines.
- (line 793)
-* __fractuhaqi: Fixed-point fractional library routines.
- (line 816)
-* __fractuhaqq: Fixed-point fractional library routines.
- (line 792)
-* __fractuhasa: Fixed-point fractional library routines.
- (line 798)
-* __fractuhasf: Fixed-point fractional library routines.
- (line 821)
-* __fractuhasi: Fixed-point fractional library routines.
- (line 818)
-* __fractuhasq: Fixed-point fractional library routines.
- (line 794)
-* __fractuhata: Fixed-point fractional library routines.
- (line 801)
-* __fractuhati: Fixed-point fractional library routines.
- (line 820)
-* __fractuhauda2: Fixed-point fractional library routines.
- (line 813)
-* __fractuhaudq: Fixed-point fractional library routines.
- (line 809)
-* __fractuhauhq: Fixed-point fractional library routines.
- (line 805)
-* __fractuhauqq: Fixed-point fractional library routines.
- (line 803)
-* __fractuhausa2: Fixed-point fractional library routines.
- (line 811)
-* __fractuhausq: Fixed-point fractional library routines.
- (line 807)
-* __fractuhauta2: Fixed-point fractional library routines.
- (line 815)
-* __fractuhqda: Fixed-point fractional library routines.
- (line 702)
-* __fractuhqdf: Fixed-point fractional library routines.
- (line 723)
-* __fractuhqdi: Fixed-point fractional library routines.
- (line 720)
-* __fractuhqdq: Fixed-point fractional library routines.
- (line 699)
-* __fractuhqha: Fixed-point fractional library routines.
- (line 700)
-* __fractuhqhi: Fixed-point fractional library routines.
- (line 718)
-* __fractuhqhq: Fixed-point fractional library routines.
- (line 697)
-* __fractuhqqi: Fixed-point fractional library routines.
- (line 717)
-* __fractuhqqq: Fixed-point fractional library routines.
- (line 696)
-* __fractuhqsa: Fixed-point fractional library routines.
- (line 701)
-* __fractuhqsf: Fixed-point fractional library routines.
- (line 722)
-* __fractuhqsi: Fixed-point fractional library routines.
- (line 719)
-* __fractuhqsq: Fixed-point fractional library routines.
- (line 698)
-* __fractuhqta: Fixed-point fractional library routines.
- (line 703)
-* __fractuhqti: Fixed-point fractional library routines.
- (line 721)
-* __fractuhquda: Fixed-point fractional library routines.
- (line 714)
-* __fractuhqudq2: Fixed-point fractional library routines.
- (line 709)
-* __fractuhquha: Fixed-point fractional library routines.
- (line 711)
-* __fractuhquqq2: Fixed-point fractional library routines.
- (line 705)
-* __fractuhqusa: Fixed-point fractional library routines.
- (line 712)
-* __fractuhqusq2: Fixed-point fractional library routines.
- (line 707)
-* __fractuhquta: Fixed-point fractional library routines.
- (line 716)
-* __fractunsdadi: Fixed-point fractional library routines.
- (line 1555)
-* __fractunsdahi: Fixed-point fractional library routines.
- (line 1553)
-* __fractunsdaqi: Fixed-point fractional library routines.
- (line 1552)
-* __fractunsdasi: Fixed-point fractional library routines.
- (line 1554)
-* __fractunsdati: Fixed-point fractional library routines.
- (line 1556)
-* __fractunsdida: Fixed-point fractional library routines.
- (line 1707)
-* __fractunsdidq: Fixed-point fractional library routines.
- (line 1704)
-* __fractunsdiha: Fixed-point fractional library routines.
- (line 1705)
-* __fractunsdihq: Fixed-point fractional library routines.
- (line 1702)
-* __fractunsdiqq: Fixed-point fractional library routines.
- (line 1701)
-* __fractunsdisa: Fixed-point fractional library routines.
- (line 1706)
-* __fractunsdisq: Fixed-point fractional library routines.
- (line 1703)
-* __fractunsdita: Fixed-point fractional library routines.
- (line 1708)
-* __fractunsdiuda: Fixed-point fractional library routines.
- (line 1720)
-* __fractunsdiudq: Fixed-point fractional library routines.
- (line 1715)
-* __fractunsdiuha: Fixed-point fractional library routines.
- (line 1717)
-* __fractunsdiuhq: Fixed-point fractional library routines.
- (line 1711)
-* __fractunsdiuqq: Fixed-point fractional library routines.
- (line 1710)
-* __fractunsdiusa: Fixed-point fractional library routines.
- (line 1718)
-* __fractunsdiusq: Fixed-point fractional library routines.
- (line 1713)
-* __fractunsdiuta: Fixed-point fractional library routines.
- (line 1722)
-* __fractunsdqdi: Fixed-point fractional library routines.
- (line 1539)
-* __fractunsdqhi: Fixed-point fractional library routines.
- (line 1537)
-* __fractunsdqqi: Fixed-point fractional library routines.
- (line 1536)
-* __fractunsdqsi: Fixed-point fractional library routines.
- (line 1538)
-* __fractunsdqti: Fixed-point fractional library routines.
- (line 1541)
-* __fractunshadi: Fixed-point fractional library routines.
- (line 1545)
-* __fractunshahi: Fixed-point fractional library routines.
- (line 1543)
-* __fractunshaqi: Fixed-point fractional library routines.
- (line 1542)
-* __fractunshasi: Fixed-point fractional library routines.
- (line 1544)
-* __fractunshati: Fixed-point fractional library routines.
- (line 1546)
-* __fractunshida: Fixed-point fractional library routines.
- (line 1663)
-* __fractunshidq: Fixed-point fractional library routines.
- (line 1660)
-* __fractunshiha: Fixed-point fractional library routines.
- (line 1661)
-* __fractunshihq: Fixed-point fractional library routines.
- (line 1658)
-* __fractunshiqq: Fixed-point fractional library routines.
- (line 1657)
-* __fractunshisa: Fixed-point fractional library routines.
- (line 1662)
-* __fractunshisq: Fixed-point fractional library routines.
- (line 1659)
-* __fractunshita: Fixed-point fractional library routines.
- (line 1664)
-* __fractunshiuda: Fixed-point fractional library routines.
- (line 1676)
-* __fractunshiudq: Fixed-point fractional library routines.
- (line 1671)
-* __fractunshiuha: Fixed-point fractional library routines.
- (line 1673)
-* __fractunshiuhq: Fixed-point fractional library routines.
- (line 1667)
-* __fractunshiuqq: Fixed-point fractional library routines.
- (line 1666)
-* __fractunshiusa: Fixed-point fractional library routines.
- (line 1674)
-* __fractunshiusq: Fixed-point fractional library routines.
- (line 1669)
-* __fractunshiuta: Fixed-point fractional library routines.
- (line 1678)
-* __fractunshqdi: Fixed-point fractional library routines.
- (line 1529)
-* __fractunshqhi: Fixed-point fractional library routines.
- (line 1527)
-* __fractunshqqi: Fixed-point fractional library routines.
- (line 1526)
-* __fractunshqsi: Fixed-point fractional library routines.
- (line 1528)
-* __fractunshqti: Fixed-point fractional library routines.
- (line 1530)
-* __fractunsqida: Fixed-point fractional library routines.
- (line 1641)
-* __fractunsqidq: Fixed-point fractional library routines.
- (line 1638)
-* __fractunsqiha: Fixed-point fractional library routines.
- (line 1639)
-* __fractunsqihq: Fixed-point fractional library routines.
- (line 1636)
-* __fractunsqiqq: Fixed-point fractional library routines.
- (line 1635)
-* __fractunsqisa: Fixed-point fractional library routines.
- (line 1640)
-* __fractunsqisq: Fixed-point fractional library routines.
- (line 1637)
-* __fractunsqita: Fixed-point fractional library routines.
- (line 1642)
-* __fractunsqiuda: Fixed-point fractional library routines.
- (line 1654)
-* __fractunsqiudq: Fixed-point fractional library routines.
- (line 1649)
-* __fractunsqiuha: Fixed-point fractional library routines.
- (line 1651)
-* __fractunsqiuhq: Fixed-point fractional library routines.
- (line 1645)
-* __fractunsqiuqq: Fixed-point fractional library routines.
- (line 1644)
-* __fractunsqiusa: Fixed-point fractional library routines.
- (line 1652)
-* __fractunsqiusq: Fixed-point fractional library routines.
- (line 1647)
-* __fractunsqiuta: Fixed-point fractional library routines.
- (line 1656)
-* __fractunsqqdi: Fixed-point fractional library routines.
- (line 1524)
-* __fractunsqqhi: Fixed-point fractional library routines.
- (line 1522)
-* __fractunsqqqi: Fixed-point fractional library routines.
- (line 1521)
-* __fractunsqqsi: Fixed-point fractional library routines.
- (line 1523)
-* __fractunsqqti: Fixed-point fractional library routines.
- (line 1525)
-* __fractunssadi: Fixed-point fractional library routines.
- (line 1550)
-* __fractunssahi: Fixed-point fractional library routines.
- (line 1548)
-* __fractunssaqi: Fixed-point fractional library routines.
- (line 1547)
-* __fractunssasi: Fixed-point fractional library routines.
- (line 1549)
-* __fractunssati: Fixed-point fractional library routines.
- (line 1551)
-* __fractunssida: Fixed-point fractional library routines.
- (line 1685)
-* __fractunssidq: Fixed-point fractional library routines.
- (line 1682)
-* __fractunssiha: Fixed-point fractional library routines.
- (line 1683)
-* __fractunssihq: Fixed-point fractional library routines.
- (line 1680)
-* __fractunssiqq: Fixed-point fractional library routines.
- (line 1679)
-* __fractunssisa: Fixed-point fractional library routines.
- (line 1684)
-* __fractunssisq: Fixed-point fractional library routines.
- (line 1681)
-* __fractunssita: Fixed-point fractional library routines.
- (line 1686)
-* __fractunssiuda: Fixed-point fractional library routines.
- (line 1698)
-* __fractunssiudq: Fixed-point fractional library routines.
- (line 1693)
-* __fractunssiuha: Fixed-point fractional library routines.
- (line 1695)
-* __fractunssiuhq: Fixed-point fractional library routines.
- (line 1689)
-* __fractunssiuqq: Fixed-point fractional library routines.
- (line 1688)
-* __fractunssiusa: Fixed-point fractional library routines.
- (line 1696)
-* __fractunssiusq: Fixed-point fractional library routines.
- (line 1691)
-* __fractunssiuta: Fixed-point fractional library routines.
- (line 1700)
-* __fractunssqdi: Fixed-point fractional library routines.
- (line 1534)
-* __fractunssqhi: Fixed-point fractional library routines.
- (line 1532)
-* __fractunssqqi: Fixed-point fractional library routines.
- (line 1531)
-* __fractunssqsi: Fixed-point fractional library routines.
- (line 1533)
-* __fractunssqti: Fixed-point fractional library routines.
- (line 1535)
-* __fractunstadi: Fixed-point fractional library routines.
- (line 1560)
-* __fractunstahi: Fixed-point fractional library routines.
- (line 1558)
-* __fractunstaqi: Fixed-point fractional library routines.
- (line 1557)
-* __fractunstasi: Fixed-point fractional library routines.
- (line 1559)
-* __fractunstati: Fixed-point fractional library routines.
- (line 1562)
-* __fractunstida: Fixed-point fractional library routines.
- (line 1730)
-* __fractunstidq: Fixed-point fractional library routines.
- (line 1727)
-* __fractunstiha: Fixed-point fractional library routines.
- (line 1728)
-* __fractunstihq: Fixed-point fractional library routines.
- (line 1724)
-* __fractunstiqq: Fixed-point fractional library routines.
- (line 1723)
-* __fractunstisa: Fixed-point fractional library routines.
- (line 1729)
-* __fractunstisq: Fixed-point fractional library routines.
- (line 1725)
-* __fractunstita: Fixed-point fractional library routines.
- (line 1732)
-* __fractunstiuda: Fixed-point fractional library routines.
- (line 1746)
-* __fractunstiudq: Fixed-point fractional library routines.
- (line 1740)
-* __fractunstiuha: Fixed-point fractional library routines.
- (line 1742)
-* __fractunstiuhq: Fixed-point fractional library routines.
- (line 1736)
-* __fractunstiuqq: Fixed-point fractional library routines.
- (line 1734)
-* __fractunstiusa: Fixed-point fractional library routines.
- (line 1744)
-* __fractunstiusq: Fixed-point fractional library routines.
- (line 1738)
-* __fractunstiuta: Fixed-point fractional library routines.
- (line 1748)
-* __fractunsudadi: Fixed-point fractional library routines.
- (line 1622)
-* __fractunsudahi: Fixed-point fractional library routines.
- (line 1618)
-* __fractunsudaqi: Fixed-point fractional library routines.
- (line 1616)
-* __fractunsudasi: Fixed-point fractional library routines.
- (line 1620)
-* __fractunsudati: Fixed-point fractional library routines.
- (line 1624)
-* __fractunsudqdi: Fixed-point fractional library routines.
- (line 1596)
-* __fractunsudqhi: Fixed-point fractional library routines.
- (line 1592)
-* __fractunsudqqi: Fixed-point fractional library routines.
- (line 1590)
-* __fractunsudqsi: Fixed-point fractional library routines.
- (line 1594)
-* __fractunsudqti: Fixed-point fractional library routines.
- (line 1598)
-* __fractunsuhadi: Fixed-point fractional library routines.
- (line 1606)
-* __fractunsuhahi: Fixed-point fractional library routines.
- (line 1602)
-* __fractunsuhaqi: Fixed-point fractional library routines.
- (line 1600)
-* __fractunsuhasi: Fixed-point fractional library routines.
- (line 1604)
-* __fractunsuhati: Fixed-point fractional library routines.
- (line 1608)
-* __fractunsuhqdi: Fixed-point fractional library routines.
- (line 1576)
-* __fractunsuhqhi: Fixed-point fractional library routines.
- (line 1574)
-* __fractunsuhqqi: Fixed-point fractional library routines.
- (line 1573)
-* __fractunsuhqsi: Fixed-point fractional library routines.
- (line 1575)
-* __fractunsuhqti: Fixed-point fractional library routines.
- (line 1578)
-* __fractunsuqqdi: Fixed-point fractional library routines.
- (line 1570)
-* __fractunsuqqhi: Fixed-point fractional library routines.
- (line 1566)
-* __fractunsuqqqi: Fixed-point fractional library routines.
- (line 1564)
-* __fractunsuqqsi: Fixed-point fractional library routines.
- (line 1568)
-* __fractunsuqqti: Fixed-point fractional library routines.
- (line 1572)
-* __fractunsusadi: Fixed-point fractional library routines.
- (line 1612)
-* __fractunsusahi: Fixed-point fractional library routines.
- (line 1610)
-* __fractunsusaqi: Fixed-point fractional library routines.
- (line 1609)
-* __fractunsusasi: Fixed-point fractional library routines.
- (line 1611)
-* __fractunsusati: Fixed-point fractional library routines.
- (line 1614)
-* __fractunsusqdi: Fixed-point fractional library routines.
- (line 1586)
-* __fractunsusqhi: Fixed-point fractional library routines.
- (line 1582)
-* __fractunsusqqi: Fixed-point fractional library routines.
- (line 1580)
-* __fractunsusqsi: Fixed-point fractional library routines.
- (line 1584)
-* __fractunsusqti: Fixed-point fractional library routines.
- (line 1588)
-* __fractunsutadi: Fixed-point fractional library routines.
- (line 1632)
-* __fractunsutahi: Fixed-point fractional library routines.
- (line 1628)
-* __fractunsutaqi: Fixed-point fractional library routines.
- (line 1626)
-* __fractunsutasi: Fixed-point fractional library routines.
- (line 1630)
-* __fractunsutati: Fixed-point fractional library routines.
- (line 1634)
-* __fractuqqda: Fixed-point fractional library routines.
- (line 672)
-* __fractuqqdf: Fixed-point fractional library routines.
- (line 695)
-* __fractuqqdi: Fixed-point fractional library routines.
- (line 692)
-* __fractuqqdq: Fixed-point fractional library routines.
- (line 669)
-* __fractuqqha: Fixed-point fractional library routines.
- (line 670)
-* __fractuqqhi: Fixed-point fractional library routines.
- (line 690)
-* __fractuqqhq: Fixed-point fractional library routines.
- (line 666)
-* __fractuqqqi: Fixed-point fractional library routines.
- (line 689)
-* __fractuqqqq: Fixed-point fractional library routines.
- (line 665)
-* __fractuqqsa: Fixed-point fractional library routines.
- (line 671)
-* __fractuqqsf: Fixed-point fractional library routines.
- (line 694)
-* __fractuqqsi: Fixed-point fractional library routines.
- (line 691)
-* __fractuqqsq: Fixed-point fractional library routines.
- (line 667)
-* __fractuqqta: Fixed-point fractional library routines.
- (line 674)
-* __fractuqqti: Fixed-point fractional library routines.
- (line 693)
-* __fractuqquda: Fixed-point fractional library routines.
- (line 686)
-* __fractuqqudq2: Fixed-point fractional library routines.
- (line 680)
-* __fractuqquha: Fixed-point fractional library routines.
- (line 682)
-* __fractuqquhq2: Fixed-point fractional library routines.
- (line 676)
-* __fractuqqusa: Fixed-point fractional library routines.
- (line 684)
-* __fractuqqusq2: Fixed-point fractional library routines.
- (line 678)
-* __fractuqquta: Fixed-point fractional library routines.
- (line 688)
-* __fractusada: Fixed-point fractional library routines.
- (line 829)
-* __fractusadf: Fixed-point fractional library routines.
- (line 850)
-* __fractusadi: Fixed-point fractional library routines.
- (line 847)
-* __fractusadq: Fixed-point fractional library routines.
- (line 826)
-* __fractusaha: Fixed-point fractional library routines.
- (line 827)
-* __fractusahi: Fixed-point fractional library routines.
- (line 845)
-* __fractusahq: Fixed-point fractional library routines.
- (line 824)
-* __fractusaqi: Fixed-point fractional library routines.
- (line 844)
-* __fractusaqq: Fixed-point fractional library routines.
- (line 823)
-* __fractusasa: Fixed-point fractional library routines.
- (line 828)
-* __fractusasf: Fixed-point fractional library routines.
- (line 849)
-* __fractusasi: Fixed-point fractional library routines.
- (line 846)
-* __fractusasq: Fixed-point fractional library routines.
- (line 825)
-* __fractusata: Fixed-point fractional library routines.
- (line 830)
-* __fractusati: Fixed-point fractional library routines.
- (line 848)
-* __fractusauda2: Fixed-point fractional library routines.
- (line 841)
-* __fractusaudq: Fixed-point fractional library routines.
- (line 837)
-* __fractusauha2: Fixed-point fractional library routines.
- (line 839)
-* __fractusauhq: Fixed-point fractional library routines.
- (line 833)
-* __fractusauqq: Fixed-point fractional library routines.
- (line 832)
-* __fractusausq: Fixed-point fractional library routines.
- (line 835)
-* __fractusauta2: Fixed-point fractional library routines.
- (line 843)
-* __fractusqda: Fixed-point fractional library routines.
- (line 731)
-* __fractusqdf: Fixed-point fractional library routines.
- (line 754)
-* __fractusqdi: Fixed-point fractional library routines.
- (line 751)
-* __fractusqdq: Fixed-point fractional library routines.
- (line 728)
-* __fractusqha: Fixed-point fractional library routines.
- (line 729)
-* __fractusqhi: Fixed-point fractional library routines.
- (line 749)
-* __fractusqhq: Fixed-point fractional library routines.
- (line 725)
-* __fractusqqi: Fixed-point fractional library routines.
- (line 748)
-* __fractusqqq: Fixed-point fractional library routines.
- (line 724)
-* __fractusqsa: Fixed-point fractional library routines.
- (line 730)
-* __fractusqsf: Fixed-point fractional library routines.
- (line 753)
-* __fractusqsi: Fixed-point fractional library routines.
- (line 750)
-* __fractusqsq: Fixed-point fractional library routines.
- (line 726)
-* __fractusqta: Fixed-point fractional library routines.
- (line 733)
-* __fractusqti: Fixed-point fractional library routines.
- (line 752)
-* __fractusquda: Fixed-point fractional library routines.
- (line 745)
-* __fractusqudq2: Fixed-point fractional library routines.
- (line 739)
-* __fractusquha: Fixed-point fractional library routines.
- (line 741)
-* __fractusquhq2: Fixed-point fractional library routines.
- (line 737)
-* __fractusquqq2: Fixed-point fractional library routines.
- (line 735)
-* __fractusqusa: Fixed-point fractional library routines.
- (line 743)
-* __fractusquta: Fixed-point fractional library routines.
- (line 747)
-* __fractutada: Fixed-point fractional library routines.
- (line 893)
-* __fractutadf: Fixed-point fractional library routines.
- (line 918)
-* __fractutadi: Fixed-point fractional library routines.
- (line 914)
-* __fractutadq: Fixed-point fractional library routines.
- (line 888)
-* __fractutaha: Fixed-point fractional library routines.
- (line 890)
-* __fractutahi: Fixed-point fractional library routines.
- (line 912)
-* __fractutahq: Fixed-point fractional library routines.
- (line 884)
-* __fractutaqi: Fixed-point fractional library routines.
- (line 911)
-* __fractutaqq: Fixed-point fractional library routines.
- (line 883)
-* __fractutasa: Fixed-point fractional library routines.
- (line 891)
-* __fractutasf: Fixed-point fractional library routines.
- (line 917)
-* __fractutasi: Fixed-point fractional library routines.
- (line 913)
-* __fractutasq: Fixed-point fractional library routines.
- (line 886)
-* __fractutata: Fixed-point fractional library routines.
- (line 895)
-* __fractutati: Fixed-point fractional library routines.
- (line 916)
-* __fractutauda2: Fixed-point fractional library routines.
- (line 909)
-* __fractutaudq: Fixed-point fractional library routines.
- (line 903)
-* __fractutauha2: Fixed-point fractional library routines.
- (line 905)
-* __fractutauhq: Fixed-point fractional library routines.
- (line 899)
-* __fractutauqq: Fixed-point fractional library routines.
- (line 897)
-* __fractutausa2: Fixed-point fractional library routines.
- (line 907)
-* __fractutausq: Fixed-point fractional library routines.
- (line 901)
-* __gedf2: Soft float library routines.
- (line 206)
-* __gesf2: Soft float library routines.
- (line 205)
-* __getf2: Soft float library routines.
- (line 207)
-* __gtdf2: Soft float library routines.
- (line 224)
-* __gtsf2: Soft float library routines.
- (line 223)
-* __gttf2: Soft float library routines.
- (line 225)
-* __ledf2: Soft float library routines.
- (line 218)
-* __lesf2: Soft float library routines.
- (line 217)
-* __letf2: Soft float library routines.
- (line 219)
-* __lshrdi3: Integer library routines.
- (line 31)
-* __lshrsi3: Integer library routines.
- (line 30)
-* __lshrti3: Integer library routines.
- (line 32)
-* __lshruda3: Fixed-point fractional library routines.
- (line 390)
-* __lshrudq3: Fixed-point fractional library routines.
- (line 384)
-* __lshruha3: Fixed-point fractional library routines.
- (line 386)
-* __lshruhq3: Fixed-point fractional library routines.
- (line 380)
-* __lshruqq3: Fixed-point fractional library routines.
- (line 378)
-* __lshrusa3: Fixed-point fractional library routines.
- (line 388)
-* __lshrusq3: Fixed-point fractional library routines.
- (line 382)
-* __lshruta3: Fixed-point fractional library routines.
- (line 392)
-* __ltdf2: Soft float library routines.
- (line 212)
-* __ltsf2: Soft float library routines.
- (line 211)
-* __lttf2: Soft float library routines.
- (line 213)
-* __main: Collect2. (line 15)
-* __moddi3: Integer library routines.
- (line 37)
-* __modsi3: Integer library routines.
- (line 36)
-* __modti3: Integer library routines.
- (line 38)
-* __mulda3: Fixed-point fractional library routines.
- (line 171)
-* __muldc3: Soft float library routines.
- (line 241)
-* __muldf3: Soft float library routines.
- (line 40)
-* __muldi3: Integer library routines.
- (line 43)
-* __muldq3: Fixed-point fractional library routines.
- (line 159)
-* __mulha3: Fixed-point fractional library routines.
- (line 169)
-* __mulhq3: Fixed-point fractional library routines.
- (line 156)
-* __mulqq3: Fixed-point fractional library routines.
- (line 155)
-* __mulsa3: Fixed-point fractional library routines.
- (line 170)
-* __mulsc3: Soft float library routines.
- (line 239)
-* __mulsf3: Soft float library routines.
- (line 39)
-* __mulsi3: Integer library routines.
- (line 42)
-* __mulsq3: Fixed-point fractional library routines.
- (line 157)
-* __multa3: Fixed-point fractional library routines.
- (line 173)
-* __multc3: Soft float library routines.
- (line 243)
-* __multf3: Soft float library routines.
- (line 42)
-* __multi3: Integer library routines.
- (line 44)
-* __muluda3: Fixed-point fractional library routines.
- (line 179)
-* __muludq3: Fixed-point fractional library routines.
- (line 167)
-* __muluha3: Fixed-point fractional library routines.
- (line 175)
-* __muluhq3: Fixed-point fractional library routines.
- (line 163)
-* __muluqq3: Fixed-point fractional library routines.
- (line 161)
-* __mulusa3: Fixed-point fractional library routines.
- (line 177)
-* __mulusq3: Fixed-point fractional library routines.
- (line 165)
-* __muluta3: Fixed-point fractional library routines.
- (line 181)
-* __mulvdi3: Integer library routines.
- (line 115)
-* __mulvsi3: Integer library routines.
- (line 114)
-* __mulxc3: Soft float library routines.
- (line 245)
-* __mulxf3: Soft float library routines.
- (line 44)
-* __nedf2: Soft float library routines.
- (line 200)
-* __negda2: Fixed-point fractional library routines.
- (line 299)
-* __negdf2: Soft float library routines.
- (line 56)
-* __negdi2: Integer library routines.
- (line 47)
-* __negdq2: Fixed-point fractional library routines.
- (line 289)
-* __negha2: Fixed-point fractional library routines.
- (line 297)
-* __neghq2: Fixed-point fractional library routines.
- (line 287)
-* __negqq2: Fixed-point fractional library routines.
- (line 286)
-* __negsa2: Fixed-point fractional library routines.
- (line 298)
-* __negsf2: Soft float library routines.
- (line 55)
-* __negsq2: Fixed-point fractional library routines.
- (line 288)
-* __negta2: Fixed-point fractional library routines.
- (line 300)
-* __negtf2: Soft float library routines.
- (line 57)
-* __negti2: Integer library routines.
- (line 48)
-* __neguda2: Fixed-point fractional library routines.
- (line 305)
-* __negudq2: Fixed-point fractional library routines.
- (line 296)
-* __neguha2: Fixed-point fractional library routines.
- (line 302)
-* __neguhq2: Fixed-point fractional library routines.
- (line 292)
-* __neguqq2: Fixed-point fractional library routines.
- (line 291)
-* __negusa2: Fixed-point fractional library routines.
- (line 303)
-* __negusq2: Fixed-point fractional library routines.
- (line 294)
-* __neguta2: Fixed-point fractional library routines.
- (line 307)
-* __negvdi2: Integer library routines.
- (line 119)
-* __negvsi2: Integer library routines.
- (line 118)
-* __negxf2: Soft float library routines.
- (line 58)
-* __nesf2: Soft float library routines.
- (line 199)
-* __netf2: Soft float library routines.
- (line 201)
-* __paritydi2: Integer library routines.
- (line 151)
-* __paritysi2: Integer library routines.
- (line 150)
-* __parityti2: Integer library routines.
- (line 152)
-* __popcountdi2: Integer library routines.
- (line 157)
-* __popcountsi2: Integer library routines.
- (line 156)
-* __popcountti2: Integer library routines.
- (line 158)
-* __powidf2: Soft float library routines.
- (line 233)
-* __powisf2: Soft float library routines.
- (line 232)
-* __powitf2: Soft float library routines.
- (line 234)
-* __powixf2: Soft float library routines.
- (line 235)
-* __satfractdadq: Fixed-point fractional library routines.
- (line 1153)
-* __satfractdaha2: Fixed-point fractional library routines.
- (line 1154)
-* __satfractdahq: Fixed-point fractional library routines.
- (line 1151)
-* __satfractdaqq: Fixed-point fractional library routines.
- (line 1150)
-* __satfractdasa2: Fixed-point fractional library routines.
- (line 1155)
-* __satfractdasq: Fixed-point fractional library routines.
- (line 1152)
-* __satfractdata2: Fixed-point fractional library routines.
- (line 1156)
-* __satfractdauda: Fixed-point fractional library routines.
- (line 1166)
-* __satfractdaudq: Fixed-point fractional library routines.
- (line 1162)
-* __satfractdauha: Fixed-point fractional library routines.
- (line 1164)
-* __satfractdauhq: Fixed-point fractional library routines.
- (line 1159)
-* __satfractdauqq: Fixed-point fractional library routines.
- (line 1158)
-* __satfractdausa: Fixed-point fractional library routines.
- (line 1165)
-* __satfractdausq: Fixed-point fractional library routines.
- (line 1160)
-* __satfractdauta: Fixed-point fractional library routines.
- (line 1168)
-* __satfractdfda: Fixed-point fractional library routines.
- (line 1506)
-* __satfractdfdq: Fixed-point fractional library routines.
- (line 1503)
-* __satfractdfha: Fixed-point fractional library routines.
- (line 1504)
-* __satfractdfhq: Fixed-point fractional library routines.
- (line 1501)
-* __satfractdfqq: Fixed-point fractional library routines.
- (line 1500)
-* __satfractdfsa: Fixed-point fractional library routines.
- (line 1505)
-* __satfractdfsq: Fixed-point fractional library routines.
- (line 1502)
-* __satfractdfta: Fixed-point fractional library routines.
- (line 1507)
-* __satfractdfuda: Fixed-point fractional library routines.
- (line 1515)
-* __satfractdfudq: Fixed-point fractional library routines.
- (line 1512)
-* __satfractdfuha: Fixed-point fractional library routines.
- (line 1513)
-* __satfractdfuhq: Fixed-point fractional library routines.
- (line 1509)
-* __satfractdfuqq: Fixed-point fractional library routines.
- (line 1508)
-* __satfractdfusa: Fixed-point fractional library routines.
- (line 1514)
-* __satfractdfusq: Fixed-point fractional library routines.
- (line 1510)
-* __satfractdfuta: Fixed-point fractional library routines.
- (line 1517)
-* __satfractdida: Fixed-point fractional library routines.
- (line 1456)
-* __satfractdidq: Fixed-point fractional library routines.
- (line 1453)
-* __satfractdiha: Fixed-point fractional library routines.
- (line 1454)
-* __satfractdihq: Fixed-point fractional library routines.
- (line 1451)
-* __satfractdiqq: Fixed-point fractional library routines.
- (line 1450)
-* __satfractdisa: Fixed-point fractional library routines.
- (line 1455)
-* __satfractdisq: Fixed-point fractional library routines.
- (line 1452)
-* __satfractdita: Fixed-point fractional library routines.
- (line 1457)
-* __satfractdiuda: Fixed-point fractional library routines.
- (line 1464)
-* __satfractdiudq: Fixed-point fractional library routines.
- (line 1461)
-* __satfractdiuha: Fixed-point fractional library routines.
- (line 1462)
-* __satfractdiuhq: Fixed-point fractional library routines.
- (line 1459)
-* __satfractdiuqq: Fixed-point fractional library routines.
- (line 1458)
-* __satfractdiusa: Fixed-point fractional library routines.
- (line 1463)
-* __satfractdiusq: Fixed-point fractional library routines.
- (line 1460)
-* __satfractdiuta: Fixed-point fractional library routines.
- (line 1465)
-* __satfractdqda: Fixed-point fractional library routines.
- (line 1098)
-* __satfractdqha: Fixed-point fractional library routines.
- (line 1096)
-* __satfractdqhq2: Fixed-point fractional library routines.
- (line 1094)
-* __satfractdqqq2: Fixed-point fractional library routines.
- (line 1093)
-* __satfractdqsa: Fixed-point fractional library routines.
- (line 1097)
-* __satfractdqsq2: Fixed-point fractional library routines.
- (line 1095)
-* __satfractdqta: Fixed-point fractional library routines.
- (line 1099)
-* __satfractdquda: Fixed-point fractional library routines.
- (line 1111)
-* __satfractdqudq: Fixed-point fractional library routines.
- (line 1106)
-* __satfractdquha: Fixed-point fractional library routines.
- (line 1108)
-* __satfractdquhq: Fixed-point fractional library routines.
- (line 1102)
-* __satfractdquqq: Fixed-point fractional library routines.
- (line 1101)
-* __satfractdqusa: Fixed-point fractional library routines.
- (line 1109)
-* __satfractdqusq: Fixed-point fractional library routines.
- (line 1104)
-* __satfractdquta: Fixed-point fractional library routines.
- (line 1113)
-* __satfracthada2: Fixed-point fractional library routines.
- (line 1119)
-* __satfracthadq: Fixed-point fractional library routines.
- (line 1117)
-* __satfracthahq: Fixed-point fractional library routines.
- (line 1115)
-* __satfracthaqq: Fixed-point fractional library routines.
- (line 1114)
-* __satfracthasa2: Fixed-point fractional library routines.
- (line 1118)
-* __satfracthasq: Fixed-point fractional library routines.
- (line 1116)
-* __satfracthata2: Fixed-point fractional library routines.
- (line 1120)
-* __satfracthauda: Fixed-point fractional library routines.
- (line 1132)
-* __satfracthaudq: Fixed-point fractional library routines.
- (line 1127)
-* __satfracthauha: Fixed-point fractional library routines.
- (line 1129)
-* __satfracthauhq: Fixed-point fractional library routines.
- (line 1123)
-* __satfracthauqq: Fixed-point fractional library routines.
- (line 1122)
-* __satfracthausa: Fixed-point fractional library routines.
- (line 1130)
-* __satfracthausq: Fixed-point fractional library routines.
- (line 1125)
-* __satfracthauta: Fixed-point fractional library routines.
- (line 1134)
-* __satfracthida: Fixed-point fractional library routines.
- (line 1424)
-* __satfracthidq: Fixed-point fractional library routines.
- (line 1421)
-* __satfracthiha: Fixed-point fractional library routines.
- (line 1422)
-* __satfracthihq: Fixed-point fractional library routines.
- (line 1419)
-* __satfracthiqq: Fixed-point fractional library routines.
- (line 1418)
-* __satfracthisa: Fixed-point fractional library routines.
- (line 1423)
-* __satfracthisq: Fixed-point fractional library routines.
- (line 1420)
-* __satfracthita: Fixed-point fractional library routines.
- (line 1425)
-* __satfracthiuda: Fixed-point fractional library routines.
- (line 1432)
-* __satfracthiudq: Fixed-point fractional library routines.
- (line 1429)
-* __satfracthiuha: Fixed-point fractional library routines.
- (line 1430)
-* __satfracthiuhq: Fixed-point fractional library routines.
- (line 1427)
-* __satfracthiuqq: Fixed-point fractional library routines.
- (line 1426)
-* __satfracthiusa: Fixed-point fractional library routines.
- (line 1431)
-* __satfracthiusq: Fixed-point fractional library routines.
- (line 1428)
-* __satfracthiuta: Fixed-point fractional library routines.
- (line 1433)
-* __satfracthqda: Fixed-point fractional library routines.
- (line 1064)
-* __satfracthqdq2: Fixed-point fractional library routines.
- (line 1061)
-* __satfracthqha: Fixed-point fractional library routines.
- (line 1062)
-* __satfracthqqq2: Fixed-point fractional library routines.
- (line 1059)
-* __satfracthqsa: Fixed-point fractional library routines.
- (line 1063)
-* __satfracthqsq2: Fixed-point fractional library routines.
- (line 1060)
-* __satfracthqta: Fixed-point fractional library routines.
- (line 1065)
-* __satfracthquda: Fixed-point fractional library routines.
- (line 1072)
-* __satfracthqudq: Fixed-point fractional library routines.
- (line 1069)
-* __satfracthquha: Fixed-point fractional library routines.
- (line 1070)
-* __satfracthquhq: Fixed-point fractional library routines.
- (line 1067)
-* __satfracthquqq: Fixed-point fractional library routines.
- (line 1066)
-* __satfracthqusa: Fixed-point fractional library routines.
- (line 1071)
-* __satfracthqusq: Fixed-point fractional library routines.
- (line 1068)
-* __satfracthquta: Fixed-point fractional library routines.
- (line 1073)
-* __satfractqida: Fixed-point fractional library routines.
- (line 1402)
-* __satfractqidq: Fixed-point fractional library routines.
- (line 1399)
-* __satfractqiha: Fixed-point fractional library routines.
- (line 1400)
-* __satfractqihq: Fixed-point fractional library routines.
- (line 1397)
-* __satfractqiqq: Fixed-point fractional library routines.
- (line 1396)
-* __satfractqisa: Fixed-point fractional library routines.
- (line 1401)
-* __satfractqisq: Fixed-point fractional library routines.
- (line 1398)
-* __satfractqita: Fixed-point fractional library routines.
- (line 1403)
-* __satfractqiuda: Fixed-point fractional library routines.
- (line 1415)
-* __satfractqiudq: Fixed-point fractional library routines.
- (line 1410)
-* __satfractqiuha: Fixed-point fractional library routines.
- (line 1412)
-* __satfractqiuhq: Fixed-point fractional library routines.
- (line 1406)
-* __satfractqiuqq: Fixed-point fractional library routines.
- (line 1405)
-* __satfractqiusa: Fixed-point fractional library routines.
- (line 1413)
-* __satfractqiusq: Fixed-point fractional library routines.
- (line 1408)
-* __satfractqiuta: Fixed-point fractional library routines.
- (line 1417)
-* __satfractqqda: Fixed-point fractional library routines.
- (line 1043)
-* __satfractqqdq2: Fixed-point fractional library routines.
- (line 1040)
-* __satfractqqha: Fixed-point fractional library routines.
- (line 1041)
-* __satfractqqhq2: Fixed-point fractional library routines.
- (line 1038)
-* __satfractqqsa: Fixed-point fractional library routines.
- (line 1042)
-* __satfractqqsq2: Fixed-point fractional library routines.
- (line 1039)
-* __satfractqqta: Fixed-point fractional library routines.
- (line 1044)
-* __satfractqquda: Fixed-point fractional library routines.
- (line 1056)
-* __satfractqqudq: Fixed-point fractional library routines.
- (line 1051)
-* __satfractqquha: Fixed-point fractional library routines.
- (line 1053)
-* __satfractqquhq: Fixed-point fractional library routines.
- (line 1047)
-* __satfractqquqq: Fixed-point fractional library routines.
- (line 1046)
-* __satfractqqusa: Fixed-point fractional library routines.
- (line 1054)
-* __satfractqqusq: Fixed-point fractional library routines.
- (line 1049)
-* __satfractqquta: Fixed-point fractional library routines.
- (line 1058)
-* __satfractsada2: Fixed-point fractional library routines.
- (line 1140)
-* __satfractsadq: Fixed-point fractional library routines.
- (line 1138)
-* __satfractsaha2: Fixed-point fractional library routines.
- (line 1139)
-* __satfractsahq: Fixed-point fractional library routines.
- (line 1136)
-* __satfractsaqq: Fixed-point fractional library routines.
- (line 1135)
-* __satfractsasq: Fixed-point fractional library routines.
- (line 1137)
-* __satfractsata2: Fixed-point fractional library routines.
- (line 1141)
-* __satfractsauda: Fixed-point fractional library routines.
- (line 1148)
-* __satfractsaudq: Fixed-point fractional library routines.
- (line 1145)
-* __satfractsauha: Fixed-point fractional library routines.
- (line 1146)
-* __satfractsauhq: Fixed-point fractional library routines.
- (line 1143)
-* __satfractsauqq: Fixed-point fractional library routines.
- (line 1142)
-* __satfractsausa: Fixed-point fractional library routines.
- (line 1147)
-* __satfractsausq: Fixed-point fractional library routines.
- (line 1144)
-* __satfractsauta: Fixed-point fractional library routines.
- (line 1149)
-* __satfractsfda: Fixed-point fractional library routines.
- (line 1490)
-* __satfractsfdq: Fixed-point fractional library routines.
- (line 1487)
-* __satfractsfha: Fixed-point fractional library routines.
- (line 1488)
-* __satfractsfhq: Fixed-point fractional library routines.
- (line 1485)
-* __satfractsfqq: Fixed-point fractional library routines.
- (line 1484)
-* __satfractsfsa: Fixed-point fractional library routines.
- (line 1489)
-* __satfractsfsq: Fixed-point fractional library routines.
- (line 1486)
-* __satfractsfta: Fixed-point fractional library routines.
- (line 1491)
-* __satfractsfuda: Fixed-point fractional library routines.
- (line 1498)
-* __satfractsfudq: Fixed-point fractional library routines.
- (line 1495)
-* __satfractsfuha: Fixed-point fractional library routines.
- (line 1496)
-* __satfractsfuhq: Fixed-point fractional library routines.
- (line 1493)
-* __satfractsfuqq: Fixed-point fractional library routines.
- (line 1492)
-* __satfractsfusa: Fixed-point fractional library routines.
- (line 1497)
-* __satfractsfusq: Fixed-point fractional library routines.
- (line 1494)
-* __satfractsfuta: Fixed-point fractional library routines.
- (line 1499)
-* __satfractsida: Fixed-point fractional library routines.
- (line 1440)
-* __satfractsidq: Fixed-point fractional library routines.
- (line 1437)
-* __satfractsiha: Fixed-point fractional library routines.
- (line 1438)
-* __satfractsihq: Fixed-point fractional library routines.
- (line 1435)
-* __satfractsiqq: Fixed-point fractional library routines.
- (line 1434)
-* __satfractsisa: Fixed-point fractional library routines.
- (line 1439)
-* __satfractsisq: Fixed-point fractional library routines.
- (line 1436)
-* __satfractsita: Fixed-point fractional library routines.
- (line 1441)
-* __satfractsiuda: Fixed-point fractional library routines.
- (line 1448)
-* __satfractsiudq: Fixed-point fractional library routines.
- (line 1445)
-* __satfractsiuha: Fixed-point fractional library routines.
- (line 1446)
-* __satfractsiuhq: Fixed-point fractional library routines.
- (line 1443)
-* __satfractsiuqq: Fixed-point fractional library routines.
- (line 1442)
-* __satfractsiusa: Fixed-point fractional library routines.
- (line 1447)
-* __satfractsiusq: Fixed-point fractional library routines.
- (line 1444)
-* __satfractsiuta: Fixed-point fractional library routines.
- (line 1449)
-* __satfractsqda: Fixed-point fractional library routines.
- (line 1079)
-* __satfractsqdq2: Fixed-point fractional library routines.
- (line 1076)
-* __satfractsqha: Fixed-point fractional library routines.
- (line 1077)
-* __satfractsqhq2: Fixed-point fractional library routines.
- (line 1075)
-* __satfractsqqq2: Fixed-point fractional library routines.
- (line 1074)
-* __satfractsqsa: Fixed-point fractional library routines.
- (line 1078)
-* __satfractsqta: Fixed-point fractional library routines.
- (line 1080)
-* __satfractsquda: Fixed-point fractional library routines.
- (line 1090)
-* __satfractsqudq: Fixed-point fractional library routines.
- (line 1086)
-* __satfractsquha: Fixed-point fractional library routines.
- (line 1088)
-* __satfractsquhq: Fixed-point fractional library routines.
- (line 1083)
-* __satfractsquqq: Fixed-point fractional library routines.
- (line 1082)
-* __satfractsqusa: Fixed-point fractional library routines.
- (line 1089)
-* __satfractsqusq: Fixed-point fractional library routines.
- (line 1084)
-* __satfractsquta: Fixed-point fractional library routines.
- (line 1092)
-* __satfracttada2: Fixed-point fractional library routines.
- (line 1175)
-* __satfracttadq: Fixed-point fractional library routines.
- (line 1172)
-* __satfracttaha2: Fixed-point fractional library routines.
- (line 1173)
-* __satfracttahq: Fixed-point fractional library routines.
- (line 1170)
-* __satfracttaqq: Fixed-point fractional library routines.
- (line 1169)
-* __satfracttasa2: Fixed-point fractional library routines.
- (line 1174)
-* __satfracttasq: Fixed-point fractional library routines.
- (line 1171)
-* __satfracttauda: Fixed-point fractional library routines.
- (line 1187)
-* __satfracttaudq: Fixed-point fractional library routines.
- (line 1182)
-* __satfracttauha: Fixed-point fractional library routines.
- (line 1184)
-* __satfracttauhq: Fixed-point fractional library routines.
- (line 1178)
-* __satfracttauqq: Fixed-point fractional library routines.
- (line 1177)
-* __satfracttausa: Fixed-point fractional library routines.
- (line 1185)
-* __satfracttausq: Fixed-point fractional library routines.
- (line 1180)
-* __satfracttauta: Fixed-point fractional library routines.
- (line 1189)
-* __satfracttida: Fixed-point fractional library routines.
- (line 1472)
-* __satfracttidq: Fixed-point fractional library routines.
- (line 1469)
-* __satfracttiha: Fixed-point fractional library routines.
- (line 1470)
-* __satfracttihq: Fixed-point fractional library routines.
- (line 1467)
-* __satfracttiqq: Fixed-point fractional library routines.
- (line 1466)
-* __satfracttisa: Fixed-point fractional library routines.
- (line 1471)
-* __satfracttisq: Fixed-point fractional library routines.
- (line 1468)
-* __satfracttita: Fixed-point fractional library routines.
- (line 1473)
-* __satfracttiuda: Fixed-point fractional library routines.
- (line 1481)
-* __satfracttiudq: Fixed-point fractional library routines.
- (line 1478)
-* __satfracttiuha: Fixed-point fractional library routines.
- (line 1479)
-* __satfracttiuhq: Fixed-point fractional library routines.
- (line 1475)
-* __satfracttiuqq: Fixed-point fractional library routines.
- (line 1474)
-* __satfracttiusa: Fixed-point fractional library routines.
- (line 1480)
-* __satfracttiusq: Fixed-point fractional library routines.
- (line 1476)
-* __satfracttiuta: Fixed-point fractional library routines.
- (line 1483)
-* __satfractudada: Fixed-point fractional library routines.
- (line 1351)
-* __satfractudadq: Fixed-point fractional library routines.
- (line 1347)
-* __satfractudaha: Fixed-point fractional library routines.
- (line 1349)
-* __satfractudahq: Fixed-point fractional library routines.
- (line 1344)
-* __satfractudaqq: Fixed-point fractional library routines.
- (line 1343)
-* __satfractudasa: Fixed-point fractional library routines.
- (line 1350)
-* __satfractudasq: Fixed-point fractional library routines.
- (line 1345)
-* __satfractudata: Fixed-point fractional library routines.
- (line 1353)
-* __satfractudaudq: Fixed-point fractional library routines.
- (line 1361)
-* __satfractudauha2: Fixed-point fractional library routines.
- (line 1363)
-* __satfractudauhq: Fixed-point fractional library routines.
- (line 1357)
-* __satfractudauqq: Fixed-point fractional library routines.
- (line 1355)
-* __satfractudausa2: Fixed-point fractional library routines.
- (line 1365)
-* __satfractudausq: Fixed-point fractional library routines.
- (line 1359)
-* __satfractudauta2: Fixed-point fractional library routines.
- (line 1367)
-* __satfractudqda: Fixed-point fractional library routines.
- (line 1276)
-* __satfractudqdq: Fixed-point fractional library routines.
- (line 1271)
-* __satfractudqha: Fixed-point fractional library routines.
- (line 1273)
-* __satfractudqhq: Fixed-point fractional library routines.
- (line 1267)
-* __satfractudqqq: Fixed-point fractional library routines.
- (line 1266)
-* __satfractudqsa: Fixed-point fractional library routines.
- (line 1274)
-* __satfractudqsq: Fixed-point fractional library routines.
- (line 1269)
-* __satfractudqta: Fixed-point fractional library routines.
- (line 1278)
-* __satfractudquda: Fixed-point fractional library routines.
- (line 1290)
-* __satfractudquha: Fixed-point fractional library routines.
- (line 1286)
-* __satfractudquhq2: Fixed-point fractional library routines.
- (line 1282)
-* __satfractudquqq2: Fixed-point fractional library routines.
- (line 1280)
-* __satfractudqusa: Fixed-point fractional library routines.
- (line 1288)
-* __satfractudqusq2: Fixed-point fractional library routines.
- (line 1284)
-* __satfractudquta: Fixed-point fractional library routines.
- (line 1292)
-* __satfractuhada: Fixed-point fractional library routines.
- (line 1304)
-* __satfractuhadq: Fixed-point fractional library routines.
- (line 1299)
-* __satfractuhaha: Fixed-point fractional library routines.
- (line 1301)
-* __satfractuhahq: Fixed-point fractional library routines.
- (line 1295)
-* __satfractuhaqq: Fixed-point fractional library routines.
- (line 1294)
-* __satfractuhasa: Fixed-point fractional library routines.
- (line 1302)
-* __satfractuhasq: Fixed-point fractional library routines.
- (line 1297)
-* __satfractuhata: Fixed-point fractional library routines.
- (line 1306)
-* __satfractuhauda2: Fixed-point fractional library routines.
- (line 1318)
-* __satfractuhaudq: Fixed-point fractional library routines.
- (line 1314)
-* __satfractuhauhq: Fixed-point fractional library routines.
- (line 1310)
-* __satfractuhauqq: Fixed-point fractional library routines.
- (line 1308)
-* __satfractuhausa2: Fixed-point fractional library routines.
- (line 1316)
-* __satfractuhausq: Fixed-point fractional library routines.
- (line 1312)
-* __satfractuhauta2: Fixed-point fractional library routines.
- (line 1320)
-* __satfractuhqda: Fixed-point fractional library routines.
- (line 1224)
-* __satfractuhqdq: Fixed-point fractional library routines.
- (line 1221)
-* __satfractuhqha: Fixed-point fractional library routines.
- (line 1222)
-* __satfractuhqhq: Fixed-point fractional library routines.
- (line 1219)
-* __satfractuhqqq: Fixed-point fractional library routines.
- (line 1218)
-* __satfractuhqsa: Fixed-point fractional library routines.
- (line 1223)
-* __satfractuhqsq: Fixed-point fractional library routines.
- (line 1220)
-* __satfractuhqta: Fixed-point fractional library routines.
- (line 1225)
-* __satfractuhquda: Fixed-point fractional library routines.
- (line 1236)
-* __satfractuhqudq2: Fixed-point fractional library routines.
- (line 1231)
-* __satfractuhquha: Fixed-point fractional library routines.
- (line 1233)
-* __satfractuhquqq2: Fixed-point fractional library routines.
- (line 1227)
-* __satfractuhqusa: Fixed-point fractional library routines.
- (line 1234)
-* __satfractuhqusq2: Fixed-point fractional library routines.
- (line 1229)
-* __satfractuhquta: Fixed-point fractional library routines.
- (line 1238)
-* __satfractunsdida: Fixed-point fractional library routines.
- (line 1834)
-* __satfractunsdidq: Fixed-point fractional library routines.
- (line 1831)
-* __satfractunsdiha: Fixed-point fractional library routines.
- (line 1832)
-* __satfractunsdihq: Fixed-point fractional library routines.
- (line 1828)
-* __satfractunsdiqq: Fixed-point fractional library routines.
- (line 1827)
-* __satfractunsdisa: Fixed-point fractional library routines.
- (line 1833)
-* __satfractunsdisq: Fixed-point fractional library routines.
- (line 1829)
-* __satfractunsdita: Fixed-point fractional library routines.
- (line 1836)
-* __satfractunsdiuda: Fixed-point fractional library routines.
- (line 1850)
-* __satfractunsdiudq: Fixed-point fractional library routines.
- (line 1844)
-* __satfractunsdiuha: Fixed-point fractional library routines.
- (line 1846)
-* __satfractunsdiuhq: Fixed-point fractional library routines.
- (line 1840)
-* __satfractunsdiuqq: Fixed-point fractional library routines.
- (line 1838)
-* __satfractunsdiusa: Fixed-point fractional library routines.
- (line 1848)
-* __satfractunsdiusq: Fixed-point fractional library routines.
- (line 1842)
-* __satfractunsdiuta: Fixed-point fractional library routines.
- (line 1852)
-* __satfractunshida: Fixed-point fractional library routines.
- (line 1786)
-* __satfractunshidq: Fixed-point fractional library routines.
- (line 1783)
-* __satfractunshiha: Fixed-point fractional library routines.
- (line 1784)
-* __satfractunshihq: Fixed-point fractional library routines.
- (line 1780)
-* __satfractunshiqq: Fixed-point fractional library routines.
- (line 1779)
-* __satfractunshisa: Fixed-point fractional library routines.
- (line 1785)
-* __satfractunshisq: Fixed-point fractional library routines.
- (line 1781)
-* __satfractunshita: Fixed-point fractional library routines.
- (line 1788)
-* __satfractunshiuda: Fixed-point fractional library routines.
- (line 1802)
-* __satfractunshiudq: Fixed-point fractional library routines.
- (line 1796)
-* __satfractunshiuha: Fixed-point fractional library routines.
- (line 1798)
-* __satfractunshiuhq: Fixed-point fractional library routines.
- (line 1792)
-* __satfractunshiuqq: Fixed-point fractional library routines.
- (line 1790)
-* __satfractunshiusa: Fixed-point fractional library routines.
- (line 1800)
-* __satfractunshiusq: Fixed-point fractional library routines.
- (line 1794)
-* __satfractunshiuta: Fixed-point fractional library routines.
- (line 1804)
-* __satfractunsqida: Fixed-point fractional library routines.
- (line 1760)
-* __satfractunsqidq: Fixed-point fractional library routines.
- (line 1757)
-* __satfractunsqiha: Fixed-point fractional library routines.
- (line 1758)
-* __satfractunsqihq: Fixed-point fractional library routines.
- (line 1754)
-* __satfractunsqiqq: Fixed-point fractional library routines.
- (line 1753)
-* __satfractunsqisa: Fixed-point fractional library routines.
- (line 1759)
-* __satfractunsqisq: Fixed-point fractional library routines.
- (line 1755)
-* __satfractunsqita: Fixed-point fractional library routines.
- (line 1762)
-* __satfractunsqiuda: Fixed-point fractional library routines.
- (line 1776)
-* __satfractunsqiudq: Fixed-point fractional library routines.
- (line 1770)
-* __satfractunsqiuha: Fixed-point fractional library routines.
- (line 1772)
-* __satfractunsqiuhq: Fixed-point fractional library routines.
- (line 1766)
-* __satfractunsqiuqq: Fixed-point fractional library routines.
- (line 1764)
-* __satfractunsqiusa: Fixed-point fractional library routines.
- (line 1774)
-* __satfractunsqiusq: Fixed-point fractional library routines.
- (line 1768)
-* __satfractunsqiuta: Fixed-point fractional library routines.
- (line 1778)
-* __satfractunssida: Fixed-point fractional library routines.
- (line 1811)
-* __satfractunssidq: Fixed-point fractional library routines.
- (line 1808)
-* __satfractunssiha: Fixed-point fractional library routines.
- (line 1809)
-* __satfractunssihq: Fixed-point fractional library routines.
- (line 1806)
-* __satfractunssiqq: Fixed-point fractional library routines.
- (line 1805)
-* __satfractunssisa: Fixed-point fractional library routines.
- (line 1810)
-* __satfractunssisq: Fixed-point fractional library routines.
- (line 1807)
-* __satfractunssita: Fixed-point fractional library routines.
- (line 1812)
-* __satfractunssiuda: Fixed-point fractional library routines.
- (line 1824)
-* __satfractunssiudq: Fixed-point fractional library routines.
- (line 1819)
-* __satfractunssiuha: Fixed-point fractional library routines.
- (line 1821)
-* __satfractunssiuhq: Fixed-point fractional library routines.
- (line 1815)
-* __satfractunssiuqq: Fixed-point fractional library routines.
- (line 1814)
-* __satfractunssiusa: Fixed-point fractional library routines.
- (line 1822)
-* __satfractunssiusq: Fixed-point fractional library routines.
- (line 1817)
-* __satfractunssiuta: Fixed-point fractional library routines.
- (line 1826)
-* __satfractunstida: Fixed-point fractional library routines.
- (line 1864)
-* __satfractunstidq: Fixed-point fractional library routines.
- (line 1859)
-* __satfractunstiha: Fixed-point fractional library routines.
- (line 1861)
-* __satfractunstihq: Fixed-point fractional library routines.
- (line 1855)
-* __satfractunstiqq: Fixed-point fractional library routines.
- (line 1854)
-* __satfractunstisa: Fixed-point fractional library routines.
- (line 1862)
-* __satfractunstisq: Fixed-point fractional library routines.
- (line 1857)
-* __satfractunstita: Fixed-point fractional library routines.
- (line 1866)
-* __satfractunstiuda: Fixed-point fractional library routines.
- (line 1880)
-* __satfractunstiudq: Fixed-point fractional library routines.
- (line 1874)
-* __satfractunstiuha: Fixed-point fractional library routines.
- (line 1876)
-* __satfractunstiuhq: Fixed-point fractional library routines.
- (line 1870)
-* __satfractunstiuqq: Fixed-point fractional library routines.
- (line 1868)
-* __satfractunstiusa: Fixed-point fractional library routines.
- (line 1878)
-* __satfractunstiusq: Fixed-point fractional library routines.
- (line 1872)
-* __satfractunstiuta: Fixed-point fractional library routines.
- (line 1882)
-* __satfractuqqda: Fixed-point fractional library routines.
- (line 1201)
-* __satfractuqqdq: Fixed-point fractional library routines.
- (line 1196)
-* __satfractuqqha: Fixed-point fractional library routines.
- (line 1198)
-* __satfractuqqhq: Fixed-point fractional library routines.
- (line 1192)
-* __satfractuqqqq: Fixed-point fractional library routines.
- (line 1191)
-* __satfractuqqsa: Fixed-point fractional library routines.
- (line 1199)
-* __satfractuqqsq: Fixed-point fractional library routines.
- (line 1194)
-* __satfractuqqta: Fixed-point fractional library routines.
- (line 1203)
-* __satfractuqquda: Fixed-point fractional library routines.
- (line 1215)
-* __satfractuqqudq2: Fixed-point fractional library routines.
- (line 1209)
-* __satfractuqquha: Fixed-point fractional library routines.
- (line 1211)
-* __satfractuqquhq2: Fixed-point fractional library routines.
- (line 1205)
-* __satfractuqqusa: Fixed-point fractional library routines.
- (line 1213)
-* __satfractuqqusq2: Fixed-point fractional library routines.
- (line 1207)
-* __satfractuqquta: Fixed-point fractional library routines.
- (line 1217)
-* __satfractusada: Fixed-point fractional library routines.
- (line 1327)
-* __satfractusadq: Fixed-point fractional library routines.
- (line 1324)
-* __satfractusaha: Fixed-point fractional library routines.
- (line 1325)
-* __satfractusahq: Fixed-point fractional library routines.
- (line 1322)
-* __satfractusaqq: Fixed-point fractional library routines.
- (line 1321)
-* __satfractusasa: Fixed-point fractional library routines.
- (line 1326)
-* __satfractusasq: Fixed-point fractional library routines.
- (line 1323)
-* __satfractusata: Fixed-point fractional library routines.
- (line 1328)
-* __satfractusauda2: Fixed-point fractional library routines.
- (line 1339)
-* __satfractusaudq: Fixed-point fractional library routines.
- (line 1335)
-* __satfractusauha2: Fixed-point fractional library routines.
- (line 1337)
-* __satfractusauhq: Fixed-point fractional library routines.
- (line 1331)
-* __satfractusauqq: Fixed-point fractional library routines.
- (line 1330)
-* __satfractusausq: Fixed-point fractional library routines.
- (line 1333)
-* __satfractusauta2: Fixed-point fractional library routines.
- (line 1341)
-* __satfractusqda: Fixed-point fractional library routines.
- (line 1248)
-* __satfractusqdq: Fixed-point fractional library routines.
- (line 1244)
-* __satfractusqha: Fixed-point fractional library routines.
- (line 1246)
-* __satfractusqhq: Fixed-point fractional library routines.
- (line 1241)
-* __satfractusqqq: Fixed-point fractional library routines.
- (line 1240)
-* __satfractusqsa: Fixed-point fractional library routines.
- (line 1247)
-* __satfractusqsq: Fixed-point fractional library routines.
- (line 1242)
-* __satfractusqta: Fixed-point fractional library routines.
- (line 1250)
-* __satfractusquda: Fixed-point fractional library routines.
- (line 1262)
-* __satfractusqudq2: Fixed-point fractional library routines.
- (line 1256)
-* __satfractusquha: Fixed-point fractional library routines.
- (line 1258)
-* __satfractusquhq2: Fixed-point fractional library routines.
- (line 1254)
-* __satfractusquqq2: Fixed-point fractional library routines.
- (line 1252)
-* __satfractusqusa: Fixed-point fractional library routines.
- (line 1260)
-* __satfractusquta: Fixed-point fractional library routines.
- (line 1264)
-* __satfractutada: Fixed-point fractional library routines.
- (line 1379)
-* __satfractutadq: Fixed-point fractional library routines.
- (line 1374)
-* __satfractutaha: Fixed-point fractional library routines.
- (line 1376)
-* __satfractutahq: Fixed-point fractional library routines.
- (line 1370)
-* __satfractutaqq: Fixed-point fractional library routines.
- (line 1369)
-* __satfractutasa: Fixed-point fractional library routines.
- (line 1377)
-* __satfractutasq: Fixed-point fractional library routines.
- (line 1372)
-* __satfractutata: Fixed-point fractional library routines.
- (line 1381)
-* __satfractutauda2: Fixed-point fractional library routines.
- (line 1395)
-* __satfractutaudq: Fixed-point fractional library routines.
- (line 1389)
-* __satfractutauha2: Fixed-point fractional library routines.
- (line 1391)
-* __satfractutauhq: Fixed-point fractional library routines.
- (line 1385)
-* __satfractutauqq: Fixed-point fractional library routines.
- (line 1383)
-* __satfractutausa2: Fixed-point fractional library routines.
- (line 1393)
-* __satfractutausq: Fixed-point fractional library routines.
- (line 1387)
-* __ssaddda3: Fixed-point fractional library routines.
- (line 67)
-* __ssadddq3: Fixed-point fractional library routines.
- (line 63)
-* __ssaddha3: Fixed-point fractional library routines.
- (line 65)
-* __ssaddhq3: Fixed-point fractional library routines.
- (line 60)
-* __ssaddqq3: Fixed-point fractional library routines.
- (line 59)
-* __ssaddsa3: Fixed-point fractional library routines.
- (line 66)
-* __ssaddsq3: Fixed-point fractional library routines.
- (line 61)
-* __ssaddta3: Fixed-point fractional library routines.
- (line 69)
-* __ssashlda3: Fixed-point fractional library routines.
- (line 402)
-* __ssashldq3: Fixed-point fractional library routines.
- (line 399)
-* __ssashlha3: Fixed-point fractional library routines.
- (line 400)
-* __ssashlhq3: Fixed-point fractional library routines.
- (line 396)
-* __ssashlsa3: Fixed-point fractional library routines.
- (line 401)
-* __ssashlsq3: Fixed-point fractional library routines.
- (line 397)
-* __ssashlta3: Fixed-point fractional library routines.
- (line 404)
-* __ssdivda3: Fixed-point fractional library routines.
- (line 261)
-* __ssdivdq3: Fixed-point fractional library routines.
- (line 257)
-* __ssdivha3: Fixed-point fractional library routines.
- (line 259)
-* __ssdivhq3: Fixed-point fractional library routines.
- (line 254)
-* __ssdivqq3: Fixed-point fractional library routines.
- (line 253)
-* __ssdivsa3: Fixed-point fractional library routines.
- (line 260)
-* __ssdivsq3: Fixed-point fractional library routines.
- (line 255)
-* __ssdivta3: Fixed-point fractional library routines.
- (line 263)
-* __ssmulda3: Fixed-point fractional library routines.
- (line 193)
-* __ssmuldq3: Fixed-point fractional library routines.
- (line 189)
-* __ssmulha3: Fixed-point fractional library routines.
- (line 191)
-* __ssmulhq3: Fixed-point fractional library routines.
- (line 186)
-* __ssmulqq3: Fixed-point fractional library routines.
- (line 185)
-* __ssmulsa3: Fixed-point fractional library routines.
- (line 192)
-* __ssmulsq3: Fixed-point fractional library routines.
- (line 187)
-* __ssmulta3: Fixed-point fractional library routines.
- (line 195)
-* __ssnegda2: Fixed-point fractional library routines.
- (line 316)
-* __ssnegdq2: Fixed-point fractional library routines.
- (line 313)
-* __ssnegha2: Fixed-point fractional library routines.
- (line 314)
-* __ssneghq2: Fixed-point fractional library routines.
- (line 311)
-* __ssnegqq2: Fixed-point fractional library routines.
- (line 310)
-* __ssnegsa2: Fixed-point fractional library routines.
- (line 315)
-* __ssnegsq2: Fixed-point fractional library routines.
- (line 312)
-* __ssnegta2: Fixed-point fractional library routines.
- (line 317)
-* __sssubda3: Fixed-point fractional library routines.
- (line 129)
-* __sssubdq3: Fixed-point fractional library routines.
- (line 125)
-* __sssubha3: Fixed-point fractional library routines.
- (line 127)
-* __sssubhq3: Fixed-point fractional library routines.
- (line 122)
-* __sssubqq3: Fixed-point fractional library routines.
- (line 121)
-* __sssubsa3: Fixed-point fractional library routines.
- (line 128)
-* __sssubsq3: Fixed-point fractional library routines.
- (line 123)
-* __sssubta3: Fixed-point fractional library routines.
- (line 131)
-* __subda3: Fixed-point fractional library routines.
- (line 107)
-* __subdf3: Soft float library routines.
- (line 31)
-* __subdq3: Fixed-point fractional library routines.
- (line 95)
-* __subha3: Fixed-point fractional library routines.
- (line 105)
-* __subhq3: Fixed-point fractional library routines.
- (line 92)
-* __subqq3: Fixed-point fractional library routines.
- (line 91)
-* __subsa3: Fixed-point fractional library routines.
- (line 106)
-* __subsf3: Soft float library routines.
- (line 30)
-* __subsq3: Fixed-point fractional library routines.
- (line 93)
-* __subta3: Fixed-point fractional library routines.
- (line 109)
-* __subtf3: Soft float library routines.
- (line 33)
-* __subuda3: Fixed-point fractional library routines.
- (line 115)
-* __subudq3: Fixed-point fractional library routines.
- (line 103)
-* __subuha3: Fixed-point fractional library routines.
- (line 111)
-* __subuhq3: Fixed-point fractional library routines.
- (line 99)
-* __subuqq3: Fixed-point fractional library routines.
- (line 97)
-* __subusa3: Fixed-point fractional library routines.
- (line 113)
-* __subusq3: Fixed-point fractional library routines.
- (line 101)
-* __subuta3: Fixed-point fractional library routines.
- (line 117)
-* __subvdi3: Integer library routines.
- (line 123)
-* __subvsi3: Integer library routines.
- (line 122)
-* __subxf3: Soft float library routines.
- (line 35)
-* __truncdfsf2: Soft float library routines.
- (line 76)
-* __trunctfdf2: Soft float library routines.
- (line 73)
-* __trunctfsf2: Soft float library routines.
- (line 75)
-* __truncxfdf2: Soft float library routines.
- (line 72)
-* __truncxfsf2: Soft float library routines.
- (line 74)
-* __ucmpdi2: Integer library routines.
- (line 93)
-* __ucmpti2: Integer library routines.
- (line 95)
-* __udivdi3: Integer library routines.
- (line 54)
-* __udivmoddi3: Integer library routines.
- (line 61)
-* __udivsi3: Integer library routines.
- (line 52)
-* __udivti3: Integer library routines.
- (line 56)
-* __udivuda3: Fixed-point fractional library routines.
- (line 246)
-* __udivudq3: Fixed-point fractional library routines.
- (line 240)
-* __udivuha3: Fixed-point fractional library routines.
- (line 242)
-* __udivuhq3: Fixed-point fractional library routines.
- (line 236)
-* __udivuqq3: Fixed-point fractional library routines.
- (line 234)
-* __udivusa3: Fixed-point fractional library routines.
- (line 244)
-* __udivusq3: Fixed-point fractional library routines.
- (line 238)
-* __udivuta3: Fixed-point fractional library routines.
- (line 248)
-* __umoddi3: Integer library routines.
- (line 71)
-* __umodsi3: Integer library routines.
- (line 69)
-* __umodti3: Integer library routines.
- (line 73)
-* __unorddf2: Soft float library routines.
- (line 173)
-* __unordsf2: Soft float library routines.
- (line 172)
-* __unordtf2: Soft float library routines.
- (line 174)
-* __usadduda3: Fixed-point fractional library routines.
- (line 85)
-* __usaddudq3: Fixed-point fractional library routines.
- (line 79)
-* __usadduha3: Fixed-point fractional library routines.
- (line 81)
-* __usadduhq3: Fixed-point fractional library routines.
- (line 75)
-* __usadduqq3: Fixed-point fractional library routines.
- (line 73)
-* __usaddusa3: Fixed-point fractional library routines.
- (line 83)
-* __usaddusq3: Fixed-point fractional library routines.
- (line 77)
-* __usadduta3: Fixed-point fractional library routines.
- (line 87)
-* __usashluda3: Fixed-point fractional library routines.
- (line 421)
-* __usashludq3: Fixed-point fractional library routines.
- (line 415)
-* __usashluha3: Fixed-point fractional library routines.
- (line 417)
-* __usashluhq3: Fixed-point fractional library routines.
- (line 411)
-* __usashluqq3: Fixed-point fractional library routines.
- (line 409)
-* __usashlusa3: Fixed-point fractional library routines.
- (line 419)
-* __usashlusq3: Fixed-point fractional library routines.
- (line 413)
-* __usashluta3: Fixed-point fractional library routines.
- (line 423)
-* __usdivuda3: Fixed-point fractional library routines.
- (line 280)
-* __usdivudq3: Fixed-point fractional library routines.
- (line 274)
-* __usdivuha3: Fixed-point fractional library routines.
- (line 276)
-* __usdivuhq3: Fixed-point fractional library routines.
- (line 270)
-* __usdivuqq3: Fixed-point fractional library routines.
- (line 268)
-* __usdivusa3: Fixed-point fractional library routines.
- (line 278)
-* __usdivusq3: Fixed-point fractional library routines.
- (line 272)
-* __usdivuta3: Fixed-point fractional library routines.
- (line 282)
-* __usmuluda3: Fixed-point fractional library routines.
- (line 212)
-* __usmuludq3: Fixed-point fractional library routines.
- (line 206)
-* __usmuluha3: Fixed-point fractional library routines.
- (line 208)
-* __usmuluhq3: Fixed-point fractional library routines.
- (line 202)
-* __usmuluqq3: Fixed-point fractional library routines.
- (line 200)
-* __usmulusa3: Fixed-point fractional library routines.
- (line 210)
-* __usmulusq3: Fixed-point fractional library routines.
- (line 204)
-* __usmuluta3: Fixed-point fractional library routines.
- (line 214)
-* __usneguda2: Fixed-point fractional library routines.
- (line 331)
-* __usnegudq2: Fixed-point fractional library routines.
- (line 326)
-* __usneguha2: Fixed-point fractional library routines.
- (line 328)
-* __usneguhq2: Fixed-point fractional library routines.
- (line 322)
-* __usneguqq2: Fixed-point fractional library routines.
- (line 321)
-* __usnegusa2: Fixed-point fractional library routines.
- (line 329)
-* __usnegusq2: Fixed-point fractional library routines.
- (line 324)
-* __usneguta2: Fixed-point fractional library routines.
- (line 333)
-* __ussubuda3: Fixed-point fractional library routines.
- (line 148)
-* __ussubudq3: Fixed-point fractional library routines.
- (line 142)
-* __ussubuha3: Fixed-point fractional library routines.
- (line 144)
-* __ussubuhq3: Fixed-point fractional library routines.
- (line 138)
-* __ussubuqq3: Fixed-point fractional library routines.
- (line 136)
-* __ussubusa3: Fixed-point fractional library routines.
- (line 146)
-* __ussubusq3: Fixed-point fractional library routines.
- (line 140)
-* __ussubuta3: Fixed-point fractional library routines.
- (line 150)
-* abort: Portability. (line 21)
-* abs: Arithmetic. (line 195)
-* abs and attributes: Expressions. (line 64)
-* ABS_EXPR: Expression trees. (line 6)
-* absence_set: Processor pipeline description.
- (line 215)
-* absM2 instruction pattern: Standard Names. (line 452)
-* absolute value: Arithmetic. (line 195)
-* access to operands: Accessors. (line 6)
-* access to special operands: Special Accessors. (line 6)
-* accessors: Accessors. (line 6)
-* ACCUM_TYPE_SIZE: Type Layout. (line 88)
-* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46)
-* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135)
-* ADA_LONG_TYPE_SIZE: Type Layout. (line 26)
-* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code.
- (line 6)
-* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15)
-* addM3 instruction pattern: Standard Names. (line 216)
-* addMODEcc instruction pattern: Standard Names. (line 904)
-* addr_diff_vec: Side Effects. (line 302)
-* addr_diff_vec, length of: Insn Lengths. (line 26)
-* ADDR_EXPR: Expression trees. (line 6)
-* addr_vec: Side Effects. (line 297)
-* addr_vec, length of: Insn Lengths. (line 26)
-* address constraints: Simple Constraints. (line 154)
-* address_operand <1>: Simple Constraints. (line 158)
-* address_operand: Machine-Independent Predicates.
- (line 63)
-* addressing modes: Addressing Modes. (line 6)
-* ADJUST_FIELD_ALIGN: Storage Layout. (line 201)
-* ADJUST_INSN_LENGTH: Insn Lengths. (line 35)
-* AGGR_INIT_EXPR: Expression trees. (line 6)
-* aggregates as return values: Aggregate Return. (line 6)
-* alias: Alias analysis. (line 6)
-* ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32)
-* ALL_REGS: Register Classes. (line 17)
-* allocate_stack instruction pattern: Standard Names. (line 1227)
-* alternate entry points: Insns. (line 140)
-* anchored addresses: Anchored Addresses. (line 6)
-* and: Arithmetic. (line 153)
-* and and attributes: Expressions. (line 50)
-* and, canonicalization of: Insn Canonicalizations.
- (line 57)
-* andM3 instruction pattern: Standard Names. (line 222)
-* annotations: Annotations. (line 6)
-* APPLY_RESULT_SIZE: Scalar Return. (line 95)
-* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194)
-* ARG_POINTER_REGNUM: Frame Registers. (line 41)
-* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65)
-* arg_pointer_rtx: Frame Registers. (line 85)
-* ARGS_GROW_DOWNWARD: Frame Layout. (line 35)
-* argument passing: Interface. (line 36)
-* arguments in registers: Register Arguments. (line 6)
-* arguments on stack: Stack Arguments. (line 6)
-* arithmetic library: Soft float library routines.
- (line 6)
-* arithmetic shift: Arithmetic. (line 168)
-* arithmetic shift with signed saturation: Arithmetic. (line 168)
-* arithmetic shift with unsigned saturation: Arithmetic. (line 168)
-* arithmetic, in RTL: Arithmetic. (line 6)
-* ARITHMETIC_TYPE_P: Types. (line 76)
-* array: Types. (line 6)
-* ARRAY_RANGE_REF: Expression trees. (line 6)
-* ARRAY_REF: Expression trees. (line 6)
-* ARRAY_TYPE: Types. (line 6)
-* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151)
-* ashift: Arithmetic. (line 168)
-* ashift and attributes: Expressions. (line 64)
-* ashiftrt: Arithmetic. (line 185)
-* ashiftrt and attributes: Expressions. (line 64)
-* ashlM3 instruction pattern: Standard Names. (line 431)
-* ashrM3 instruction pattern: Standard Names. (line 441)
-* ASM_APP_OFF: File Framework. (line 61)
-* ASM_APP_ON: File Framework. (line 54)
-* ASM_COMMENT_START: File Framework. (line 49)
-* ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 436)
-* ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128)
-* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87)
-* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101)
-* ASM_DECLARE_OBJECT_NAME: Label Output. (line 114)
-* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143)
-* ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 442)
-* ASM_FINAL_SPEC: Driver. (line 144)
-* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151)
-* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 354)
-* asm_fprintf: Instruction Output. (line 123)
-* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134)
-* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 338)
-* asm_input: Side Effects. (line 284)
-* asm_input and /v: Flags. (line 94)
-* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82)
-* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72)
-* asm_noperands: Insns. (line 266)
-* asm_operands and /v: Flags. (line 94)
-* asm_operands, RTL sharing: Sharing. (line 45)
-* asm_operands, usage: Assembler. (line 6)
-* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9)
-* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26)
-* ASM_OUTPUT_ALIGN: Alignment Output. (line 79)
-* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84)
-* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64)
-* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23)
-* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31)
-* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 95)
-* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 87)
-* ASM_OUTPUT_ASCII: Data Output. (line 50)
-* ASM_OUTPUT_BSS: Uninitialized Data. (line 39)
-* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51)
-* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38)
-* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10)
-* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 326)
-* ASM_OUTPUT_DEF: Label Output. (line 375)
-* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 383)
-* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42)
-* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46)
-* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 52)
-* ASM_OUTPUT_EXTERNAL: Label Output. (line 264)
-* ASM_OUTPUT_FDESC: Data Output. (line 59)
-* ASM_OUTPUT_IDENT: File Framework. (line 83)
-* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17)
-* ASM_OUTPUT_LABEL: Label Output. (line 9)
-* ASM_OUTPUT_LABEL_REF: Label Output. (line 299)
-* ASM_OUTPUT_LABELREF: Label Output. (line 285)
-* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 74)
-* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88)
-* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41)
-* ASM_OUTPUT_OPCODE: Instruction Output. (line 21)
-* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109)
-* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72)
-* ASM_OUTPUT_REG_POP: Instruction Output. (line 178)
-* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173)
-* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35)
-* ASM_OUTPUT_SKIP: Alignment Output. (line 66)
-* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68)
-* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84)
-* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 292)
-* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77)
-* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 401)
-* ASM_OUTPUT_WEAKREF: Label Output. (line 203)
-* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67)
-* ASM_SPEC: Driver. (line 136)
-* ASM_STABD_OP: DBX Options. (line 36)
-* ASM_STABN_OP: DBX Options. (line 43)
-* ASM_STABS_OP: DBX Options. (line 29)
-* ASM_WEAKEN_DECL: Label Output. (line 195)
-* ASM_WEAKEN_LABEL: Label Output. (line 182)
-* assemble_name: Label Output. (line 8)
-* assemble_name_raw: Label Output. (line 16)
-* assembler format: File Framework. (line 6)
-* assembler instructions in RTL: Assembler. (line 6)
-* ASSEMBLER_DIALECT: Instruction Output. (line 146)
-* assigning attribute values to insns: Tagging Insns. (line 6)
-* assignment operator: Function Basics. (line 6)
-* asterisk in template: Output Statement. (line 29)
-* atan2M3 instruction pattern: Standard Names. (line 522)
-* attr <1>: Tagging Insns. (line 54)
-* attr: Expressions. (line 154)
-* attr_flag: Expressions. (line 119)
-* attribute expressions: Expressions. (line 6)
-* attribute specifications: Attr Example. (line 6)
-* attribute specifications example: Attr Example. (line 6)
-* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 183)
-* attributes: Attributes. (line 6)
-* attributes, defining: Defining Attributes.
- (line 6)
-* attributes, target-specific: Target Attributes. (line 6)
-* autoincrement addressing, availability: Portability. (line 21)
-* autoincrement/decrement addressing: Simple Constraints. (line 30)
-* automata_option: Processor pipeline description.
- (line 296)
-* automaton based pipeline description: Processor pipeline description.
- (line 6)
-* automaton based scheduler: Processor pipeline description.
- (line 6)
-* AVOID_CCMODE_COPIES: Values in Registers.
- (line 153)
-* backslash: Output Template. (line 46)
-* barrier: Insns. (line 160)
-* barrier and /f: Flags. (line 125)
-* barrier and /v: Flags. (line 44)
-* BASE_REG_CLASS: Register Classes. (line 107)
-* basic block: Basic Blocks. (line 6)
-* basic-block.h: Control Flow. (line 6)
-* BASIC_BLOCK: Basic Blocks. (line 19)
-* basic_block: Basic Blocks. (line 6)
-* BB_HEAD, BB_END: Maintaining the CFG.
- (line 88)
-* bb_seq: GIMPLE sequences. (line 73)
-* bCOND instruction pattern: Standard Names. (line 941)
-* BIGGEST_ALIGNMENT: Storage Layout. (line 173)
-* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 194)
-* BImode: Machine Modes. (line 22)
-* BIND_EXPR: Expression trees. (line 6)
-* BINFO_TYPE: Classes. (line 6)
-* bit-fields: Bit-Fields. (line 6)
-* BIT_AND_EXPR: Expression trees. (line 6)
-* BIT_IOR_EXPR: Expression trees. (line 6)
-* BIT_NOT_EXPR: Expression trees. (line 6)
-* BIT_XOR_EXPR: Expression trees. (line 6)
-* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 382)
-* BITS_BIG_ENDIAN: Storage Layout. (line 12)
-* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8)
-* BITS_PER_UNIT: Storage Layout. (line 52)
-* BITS_PER_WORD: Storage Layout. (line 57)
-* bitwise complement: Arithmetic. (line 149)
-* bitwise exclusive-or: Arithmetic. (line 163)
-* bitwise inclusive-or: Arithmetic. (line 158)
-* bitwise logical-and: Arithmetic. (line 153)
-* BLKmode: Machine Modes. (line 183)
-* BLKmode, and function return values: Calls. (line 23)
-* block statement iterators <1>: Maintaining the CFG.
- (line 45)
-* block statement iterators: Basic Blocks. (line 68)
-* BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG.
- (line 40)
-* BLOCK_REG_PADDING: Register Arguments. (line 228)
-* blockage instruction pattern: Standard Names. (line 1408)
-* Blocks: Blocks. (line 6)
-* bool <1>: Exception Region Output.
- (line 60)
-* bool: Sections. (line 280)
-* BOOL_TYPE_SIZE: Type Layout. (line 44)
-* BOOLEAN_TYPE: Types. (line 6)
-* branch prediction: Profile information.
- (line 24)
-* BRANCH_COST: Costs. (line 52)
-* break_out_memory_refs: Addressing Modes. (line 130)
-* BREAK_STMT: Function Bodies. (line 6)
-* bsi_commit_edge_inserts: Maintaining the CFG.
- (line 118)
-* bsi_end_p: Maintaining the CFG.
- (line 60)
-* bsi_insert_after: Maintaining the CFG.
- (line 72)
-* bsi_insert_before: Maintaining the CFG.
- (line 78)
-* bsi_insert_on_edge: Maintaining the CFG.
- (line 118)
-* bsi_last: Maintaining the CFG.
- (line 56)
-* bsi_next: Maintaining the CFG.
- (line 64)
-* bsi_prev: Maintaining the CFG.
- (line 68)
-* bsi_remove: Maintaining the CFG.
- (line 84)
-* bsi_start: Maintaining the CFG.
- (line 52)
-* BSS_SECTION_ASM_OP: Sections. (line 68)
-* bswap: Arithmetic. (line 232)
-* btruncM2 instruction pattern: Standard Names. (line 540)
-* builtin_longjmp instruction pattern: Standard Names. (line 1313)
-* builtin_setjmp_receiver instruction pattern: Standard Names.
- (line 1303)
-* builtin_setjmp_setup instruction pattern: Standard Names. (line 1292)
-* byte_mode: Machine Modes. (line 336)
-* BYTES_BIG_ENDIAN: Storage Layout. (line 24)
-* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221)
-* C statements for assembler output: Output Statement. (line 6)
-* C/C++ Internal Representation: Trees. (line 6)
-* C99 math functions, implicit usage: Library Calls. (line 76)
-* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 114)
-* c_register_pragma: Misc. (line 404)
-* c_register_pragma_with_expansion: Misc. (line 406)
-* call <1>: Side Effects. (line 86)
-* call: Flags. (line 234)
-* call instruction pattern: Standard Names. (line 974)
-* call usage: Calls. (line 10)
-* call, in call_insn: Flags. (line 33)
-* call, in mem: Flags. (line 99)
-* call-clobbered register: Register Basics. (line 35)
-* call-saved register: Register Basics. (line 35)
-* call-used register: Register Basics. (line 35)
-* CALL_EXPR: Expression trees. (line 6)
-* call_insn: Insns. (line 95)
-* call_insn and /c: Flags. (line 33)
-* call_insn and /f: Flags. (line 125)
-* call_insn and /i: Flags. (line 24)
-* call_insn and /j: Flags. (line 179)
-* call_insn and /s: Flags. (line 49)
-* call_insn and /u: Flags. (line 19)
-* 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 1002)
-* CALL_POPS_ARGS: Stack Arguments. (line 130)
-* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46)
-* CALL_USED_REGISTERS: Register Basics. (line 35)
-* call_used_regs: Register Basics. (line 59)
-* call_value instruction pattern: Standard Names. (line 994)
-* call_value_pop instruction pattern: Standard Names. (line 1002)
-* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11)
-* calling conventions: Stack and Calling. (line 6)
-* calling functions in RTL: Calls. (line 6)
-* can_create_pseudo_p: Standard Names. (line 75)
-* CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 146)
-* CAN_ELIMINATE: Elimination. (line 71)
-* can_fallthru: Basic Blocks. (line 57)
-* canadian: Configure Terms. (line 6)
-* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 481)
-* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory.
- (line 280)
-* canonicalization of instructions: Insn Canonicalizations.
- (line 6)
-* CANONICALIZE_COMPARISON: Condition Code. (line 84)
-* canonicalize_funcptr_for_compare instruction pattern: Standard Names.
- (line 1158)
-* CASE_USE_BIT_TESTS: Misc. (line 54)
-* CASE_VALUES_THRESHOLD: Misc. (line 47)
-* CASE_VECTOR_MODE: Misc. (line 27)
-* CASE_VECTOR_PC_RELATIVE: Misc. (line 40)
-* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31)
-* casesi instruction pattern: Standard Names. (line 1082)
-* cbranchMODE4 instruction pattern: Standard Names. (line 963)
-* cc0: Regs and Memory. (line 307)
-* cc0, RTL sharing: Sharing. (line 27)
-* cc0_rtx: Regs and Memory. (line 333)
-* CC1_SPEC: Driver. (line 118)
-* CC1PLUS_SPEC: Driver. (line 126)
-* cc_status: Condition Code. (line 8)
-* CC_STATUS_MDEP: Condition Code. (line 19)
-* CC_STATUS_MDEP_INIT: Condition Code. (line 25)
-* CCmode: Machine Modes. (line 176)
-* CDImode: Machine Modes. (line 202)
-* CEIL_DIV_EXPR: Expression trees. (line 6)
-* CEIL_MOD_EXPR: Expression trees. (line 6)
-* ceilM2 instruction pattern: Standard Names. (line 556)
-* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226)
-* CFG, Control Flow Graph: Control Flow. (line 6)
-* cfghooks.h: Maintaining the CFG.
- (line 6)
-* cgraph_finalize_function: Parsing pass. (line 52)
-* chain_circular: GTY Options. (line 195)
-* chain_next: GTY Options. (line 195)
-* chain_prev: GTY Options. (line 195)
-* change_address: Standard Names. (line 47)
-* CHANGE_DYNAMIC_TYPE_EXPR: Expression trees. (line 6)
-* char <1>: Misc. (line 685)
-* char <2>: PCH Target. (line 12)
-* char <3>: Sections. (line 272)
-* char: GIMPLE_ASM. (line 53)
-* CHAR_TYPE_SIZE: Type Layout. (line 39)
-* check_stack instruction pattern: Standard Names. (line 1245)
-* CHImode: Machine Modes. (line 202)
-* class: Classes. (line 6)
-* class definitions, register: Register Classes. (line 6)
-* class preference constraints: Class Preferences. (line 6)
-* CLASS_LIKELY_SPILLED_P: Register Classes. (line 452)
-* CLASS_MAX_NREGS: Register Classes. (line 469)
-* CLASS_TYPE_P: Types. (line 80)
-* classes of RTX codes: RTL Classes. (line 6)
-* CLASSTYPE_DECLARED_CLASS: Classes. (line 6)
-* CLASSTYPE_HAS_MUTABLE: Classes. (line 80)
-* CLASSTYPE_NON_POD_P: Classes. (line 85)
-* CLEANUP_DECL: Function Bodies. (line 6)
-* CLEANUP_EXPR: Function Bodies. (line 6)
-* CLEANUP_POINT_EXPR: Expression trees. (line 6)
-* CLEANUP_STMT: Function Bodies. (line 6)
-* Cleanups: Cleanups. (line 6)
-* CLEAR_BY_PIECES_P: Costs. (line 130)
-* clear_cache instruction pattern: Standard Names. (line 1553)
-* CLEAR_INSN_CACHE: Trampolines. (line 100)
-* CLEAR_RATIO: Costs. (line 121)
-* clobber: Side Effects. (line 100)
-* clz: Arithmetic. (line 208)
-* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319)
-* clzM2 instruction pattern: Standard Names. (line 621)
-* cmpM instruction pattern: Standard Names. (line 654)
-* cmpmemM instruction pattern: Standard Names. (line 769)
-* cmpstrM instruction pattern: Standard Names. (line 750)
-* cmpstrnM instruction pattern: Standard Names. (line 738)
-* code generation RTL sequences: Expander Definitions.
- (line 6)
-* code iterators in .md files: Code Iterators. (line 6)
-* code_label: Insns. (line 119)
-* code_label and /i: Flags. (line 59)
-* code_label and /v: Flags. (line 44)
-* CODE_LABEL_NUMBER: Insns. (line 119)
-* codes, RTL expression: RTL Objects. (line 47)
-* COImode: Machine Modes. (line 202)
-* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32)
-* COLLECT_EXPORT_LIST: Misc. (line 767)
-* COLLECT_SHARED_FINI_FUNC: Macros for Initialization.
- (line 44)
-* COLLECT_SHARED_INIT_FUNC: Macros for Initialization.
- (line 33)
-* commit_edge_insertions: Maintaining the CFG.
- (line 118)
-* compare: Arithmetic. (line 43)
-* compare, canonicalization of: Insn Canonicalizations.
- (line 37)
-* comparison_operator: Machine-Independent Predicates.
- (line 111)
-* compiler passes and files: Passes. (line 6)
-* complement, bitwise: Arithmetic. (line 149)
-* COMPLEX_CST: Expression trees. (line 6)
-* COMPLEX_EXPR: Expression trees. (line 6)
-* COMPLEX_TYPE: Types. (line 6)
-* COMPONENT_REF: Expression trees. (line 6)
-* Compound Expressions: Compound Expressions.
- (line 6)
-* Compound Lvalues: Compound Lvalues. (line 6)
-* COMPOUND_EXPR: Expression trees. (line 6)
-* COMPOUND_LITERAL_EXPR: Expression trees. (line 6)
-* COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 608)
-* COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 608)
-* computed jump: Edges. (line 128)
-* computing the length of an insn: Insn Lengths. (line 6)
-* concat: Regs and Memory. (line 385)
-* concatn: Regs and Memory. (line 391)
-* cond: Comparisons. (line 90)
-* cond and attributes: Expressions. (line 37)
-* cond_exec: Side Effects. (line 248)
-* COND_EXPR: Expression trees. (line 6)
-* condition code register: Regs and Memory. (line 307)
-* condition code status: Condition Code. (line 6)
-* condition codes: Comparisons. (line 20)
-* conditional execution: Conditional Execution.
- (line 6)
-* Conditional Expressions: Conditional Expressions.
- (line 6)
-* CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60)
-* conditional_trap instruction pattern: Standard Names. (line 1379)
-* conditions, in patterns: Patterns. (line 43)
-* configuration file <1>: Host Misc. (line 6)
-* configuration file: Filesystem. (line 6)
-* configure terms: Configure Terms. (line 6)
-* CONJ_EXPR: Expression trees. (line 6)
-* const: Constants. (line 99)
-* CONST0_RTX: Constants. (line 119)
-* const0_rtx: Constants. (line 16)
-* CONST1_RTX: Constants. (line 119)
-* const1_rtx: Constants. (line 16)
-* CONST2_RTX: Constants. (line 119)
-* const2_rtx: Constants. (line 16)
-* CONST_DECL: Declarations. (line 6)
-* const_double: Constants. (line 32)
-* const_double, RTL sharing: Sharing. (line 29)
-* CONST_DOUBLE_LOW: Constants. (line 39)
-* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69)
-* CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54)
-* const_double_operand: Machine-Independent Predicates.
- (line 21)
-* const_fixed: Constants. (line 52)
-* 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 16)
-* CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49)
-* CONST_OK_FOR_LETTER_P: Old Constraints. (line 40)
-* const_string: Constants. (line 71)
-* const_string and attributes: Expressions. (line 20)
-* const_true_rtx: Constants. (line 26)
-* const_vector: Constants. (line 59)
-* const_vector, RTL sharing: Sharing. (line 32)
-* constant attributes: Constant Attributes.
- (line 6)
-* constant definitions: Constant Definitions.
- (line 6)
-* CONSTANT_ADDRESS_P: Addressing Modes. (line 29)
-* CONSTANT_ALIGNMENT: Storage Layout. (line 241)
-* CONSTANT_P: Addressing Modes. (line 35)
-* CONSTANT_POOL_ADDRESS_P: Flags. (line 10)
-* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64)
-* constants in constraints: Simple Constraints. (line 60)
-* constm1_rtx: Constants. (line 16)
-* constraint modifier characters: Modifiers. (line 6)
-* constraint, matching: Simple Constraints. (line 132)
-* CONSTRAINT_LEN: Old Constraints. (line 12)
-* constraint_num: C Constraint Interface.
- (line 38)
-* constraint_satisfied_p: C Constraint Interface.
- (line 54)
-* 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)
-* CONSTRUCTOR: Expression trees. (line 6)
-* constructor: Function Basics. (line 6)
-* constructors, automatic calls: Collect2. (line 15)
-* constructors, output of: Initialization. (line 6)
-* container: Containers. (line 6)
-* CONTINUE_STMT: Function Bodies. (line 6)
-* contributors: Contributors. (line 6)
-* controlling register usage: Register Basics. (line 76)
-* controlling the compilation driver: Driver. (line 6)
-* conventions, run-time: Interface. (line 6)
-* conversions: Conversions. (line 6)
-* CONVERT_EXPR: Expression trees. (line 6)
-* copy constructor: Function Basics. (line 6)
-* copy_rtx: Addressing Modes. (line 182)
-* copy_rtx_if_shared: Sharing. (line 64)
-* copysignM3 instruction pattern: Standard Names. (line 602)
-* cosM2 instruction pattern: Standard Names. (line 481)
-* costs of instructions: Costs. (line 6)
-* CP_INTEGRAL_TYPE: Types. (line 72)
-* cp_namespace_decls: Namespaces. (line 44)
-* CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 45)
-* CP_TYPE_CONST_P: Types. (line 36)
-* CP_TYPE_QUALS: Types. (line 6)
-* CP_TYPE_RESTRICT_P: Types. (line 42)
-* CP_TYPE_VOLATILE_P: Types. (line 39)
-* CPLUSPLUS_CPP_SPEC: Driver. (line 113)
-* CPP_SPEC: Driver. (line 106)
-* CQImode: Machine Modes. (line 202)
-* cross compilation and floating point: Floating Point. (line 6)
-* CRT_CALL_STATIC_FUNCTION: Sections. (line 112)
-* CRTSTUFF_T_CFLAGS: Target Fragment. (line 35)
-* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39)
-* CSImode: Machine Modes. (line 202)
-* CTImode: Machine Modes. (line 202)
-* ctz: Arithmetic. (line 216)
-* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320)
-* ctzM2 instruction pattern: Standard Names. (line 630)
-* CUMULATIVE_ARGS: Register Arguments. (line 127)
-* current_function_epilogue_delay_list: Function Entry. (line 181)
-* current_function_is_leaf: Leaf Functions. (line 51)
-* current_function_outgoing_args_size: Stack Arguments. (line 45)
-* current_function_pops_args: Function Entry. (line 106)
-* current_function_pretend_args_size: Function Entry. (line 112)
-* current_function_uses_only_leaf_regs: Leaf Functions. (line 51)
-* current_insn_predicate: Conditional Execution.
- (line 26)
-* DAmode: Machine Modes. (line 152)
-* data bypass: Processor pipeline description.
- (line 106)
-* data dependence delays: Processor pipeline description.
- (line 6)
-* Data Dependency Analysis: Dependency analysis.
- (line 6)
-* data structures: Per-Function Data. (line 6)
-* DATA_ALIGNMENT: Storage Layout. (line 228)
-* DATA_SECTION_ASM_OP: Sections. (line 53)
-* DBR_OUTPUT_SEQEND: Instruction Output. (line 107)
-* dbr_sequence_length: Instruction Output. (line 106)
-* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103)
-* DBX_CONTIN_CHAR: DBX Options. (line 66)
-* DBX_CONTIN_LENGTH: DBX Options. (line 56)
-* DBX_DEBUGGING_INFO: DBX Options. (line 9)
-* DBX_FUNCTION_FIRST: DBX Options. (line 97)
-* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109)
-* DBX_NO_XREFS: DBX Options. (line 50)
-* DBX_OUTPUT_LBRAC: DBX Hooks. (line 9)
-* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34)
-* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9)
-* DBX_OUTPUT_NFUN: DBX Hooks. (line 18)
-* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
- (line 42)
-* DBX_OUTPUT_RBRAC: DBX Hooks. (line 15)
-* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22)
-* DBX_REGISTER_NUMBER: All Debuggers. (line 9)
-* DBX_REGPARM_STABS_CODE: DBX Options. (line 87)
-* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92)
-* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82)
-* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73)
-* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78)
-* DBX_USE_BINCL: DBX Options. (line 115)
-* DCmode: Machine Modes. (line 197)
-* DDmode: Machine Modes. (line 90)
-* De Morgan's law: Insn Canonicalizations.
- (line 57)
-* dead_or_set_p: define_peephole. (line 65)
-* DEBUG_SYMS_TEXT: DBX Options. (line 25)
-* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37)
-* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28)
-* decimal float library: Decimal float library routines.
- (line 6)
-* DECL_ALIGN: Declarations. (line 6)
-* DECL_ANTICIPATED: Function Basics. (line 48)
-* DECL_ARGUMENTS: Function Basics. (line 163)
-* DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 184)
-* DECL_ARTIFICIAL <1>: Function Basics. (line 6)
-* DECL_ARTIFICIAL: Working with declarations.
- (line 24)
-* DECL_ASSEMBLER_NAME: Function Basics. (line 6)
-* DECL_ATTRIBUTES: Attributes. (line 22)
-* DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 94)
-* DECL_CLASS_SCOPE_P: Working with declarations.
- (line 41)
-* DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 90)
-* DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 104)
-* DECL_CONST_MEMFUNC_P: Function Basics. (line 77)
-* DECL_CONSTRUCTOR_P: Function Basics. (line 6)
-* DECL_CONTEXT: Namespaces. (line 26)
-* DECL_CONV_FN_P: Function Basics. (line 6)
-* DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 98)
-* DECL_DESTRUCTOR_P: Function Basics. (line 6)
-* DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 52)
-* DECL_EXTERNAL <1>: Function Basics. (line 38)
-* DECL_EXTERNAL: Declarations. (line 6)
-* DECL_FUNCTION_MEMBER_P: Function Basics. (line 6)
-* DECL_FUNCTION_SCOPE_P: Working with declarations.
- (line 44)
-* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6)
-* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6)
-* DECL_GLOBAL_CTOR_P: Function Basics. (line 6)
-* DECL_GLOBAL_DTOR_P: Function Basics. (line 6)
-* DECL_INITIAL: Declarations. (line 6)
-* DECL_LINKONCE_P: Function Basics. (line 6)
-* DECL_LOCAL_FUNCTION_P: Function Basics. (line 44)
-* DECL_MAIN_P: Function Basics. (line 7)
-* DECL_NAME <1>: Function Basics. (line 6)
-* DECL_NAME <2>: Working with declarations.
- (line 7)
-* DECL_NAME: Namespaces. (line 15)
-* DECL_NAMESPACE_ALIAS: Namespaces. (line 30)
-* DECL_NAMESPACE_SCOPE_P: Working with declarations.
- (line 37)
-* DECL_NAMESPACE_STD_P: Namespaces. (line 40)
-* DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 144)
-* DECL_NONCONVERTING_P: Function Basics. (line 86)
-* DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 74)
-* DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 6)
-* DECL_RESULT: Function Basics. (line 168)
-* DECL_SIZE: Declarations. (line 6)
-* DECL_STATIC_FUNCTION_P: Function Basics. (line 71)
-* DECL_STMT: Function Bodies. (line 6)
-* DECL_STMT_DECL: Function Bodies. (line 6)
-* DECL_THUNK_P: Function Basics. (line 122)
-* DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 80)
-* declaration: Declarations. (line 6)
-* declarations, RTL: RTL Declarations. (line 6)
-* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9)
-* decrement_and_branch_until_zero instruction pattern: Standard Names.
- (line 1120)
-* def_optype_d: Manipulating GIMPLE statements.
- (line 94)
-* default: GTY Options. (line 81)
-* default_file_start: File Framework. (line 9)
-* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18)
-* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34)
-* DEFAULT_SIGNED_CHAR: Type Layout. (line 154)
-* define_address_constraint: Define Constraints. (line 107)
-* 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 197)
-* 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 48)
-* define_cpu_unit: Processor pipeline description.
- (line 68)
-* define_delay: Delay Slots. (line 25)
-* 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 106)
-* define_memory_constraint: Define Constraints. (line 88)
-* 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 28)
-* define_reservation: Processor pipeline description.
- (line 186)
-* define_special_predicate: Defining Predicates.
- (line 6)
-* define_split: Insn Splitting. (line 32)
-* 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)
-* DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163)
-* deletable: GTY Options. (line 149)
-* DELETE_IF_ORDINARY: Filesystem. (line 79)
-* Dependent Patterns: Dependent Patterns. (line 6)
-* desc: GTY Options. (line 81)
-* destructor: Function Basics. (line 6)
-* destructors, output of: Initialization. (line 6)
-* deterministic finite state automaton: Processor pipeline description.
- (line 6)
-* DF_SIZE: Type Layout. (line 130)
-* DFmode: Machine Modes. (line 73)
-* digits in constraint: Simple Constraints. (line 120)
-* DImode: Machine Modes. (line 45)
-* DIR_SEPARATOR: Filesystem. (line 18)
-* DIR_SEPARATOR_2: Filesystem. (line 19)
-* directory options .md: Including Patterns. (line 44)
-* disabling certain registers: Register Basics. (line 76)
-* dispatch table: Dispatch Tables. (line 8)
-* div: Arithmetic. (line 111)
-* div and attributes: Expressions. (line 64)
-* division: Arithmetic. (line 111)
-* divM3 instruction pattern: Standard Names. (line 222)
-* divmodM4 instruction pattern: Standard Names. (line 411)
-* DO_BODY: Function Bodies. (line 6)
-* DO_COND: Function Bodies. (line 6)
-* DO_STMT: Function Bodies. (line 6)
-* DOLLARS_IN_IDENTIFIERS: Misc. (line 488)
-* doloop_begin instruction pattern: Standard Names. (line 1151)
-* doloop_end instruction pattern: Standard Names. (line 1130)
-* DONE: Expander Definitions.
- (line 74)
-* DONT_USE_BUILTIN_SETJMP: Exception Region Output.
- (line 70)
-* DOUBLE_TYPE_SIZE: Type Layout. (line 53)
-* DQmode: Machine Modes. (line 115)
-* driver: Driver. (line 6)
-* DRIVER_SELF_SPECS: Driver. (line 71)
-* DUMPFILE_FORMAT: Filesystem. (line 67)
-* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36)
-* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13)
-* DWARF2_FRAME_INFO: SDB and DWARF. (line 30)
-* DWARF2_FRAME_REG_OUT: Frame Registers. (line 133)
-* DWARF2_UNWIND_INFO: Exception Region Output.
- (line 40)
-* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152)
-* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output.
- (line 75)
-* DWARF_FRAME_REGISTERS: Frame Registers. (line 93)
-* DWARF_FRAME_REGNUM: Frame Registers. (line 125)
-* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117)
-* DWARF_ZERO_REG: Frame Layout. (line 163)
-* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92)
-* E in constraint: Simple Constraints. (line 79)
-* 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 118)
-* EDGE_ABNORMAL: Edges. (line 128)
-* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171)
-* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96)
-* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122)
-* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86)
-* EDOM, implicit usage: Library Calls. (line 58)
-* EH_FRAME_IN_DATA_SECTION: Exception Region Output.
- (line 20)
-* EH_FRAME_SECTION_NAME: Exception Region Output.
- (line 10)
-* eh_return instruction pattern: Standard Names. (line 1319)
-* EH_RETURN_DATA_REGNO: Exception Handling. (line 7)
-* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39)
-* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22)
-* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output.
- (line 29)
-* EH_USES: Function Entry. (line 158)
-* 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)
-* ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169)
-* ELIMINABLE_REGS: Elimination. (line 44)
-* ELSE_CLAUSE: Function Bodies. (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: Function Bodies. (line 6)
-* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 295)
-* Emulated TLS: Emulated TLS. (line 6)
-* ENABLE_EXECUTE_STACK: Trampolines. (line 110)
-* enabled: Disable Insn Alternatives.
- (line 6)
-* ENDFILE_SPEC: Driver. (line 218)
-* endianness: Portability. (line 21)
-* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28)
-* enum machine_mode: Machine Modes. (line 6)
-* enum reg_class: Register Classes. (line 65)
-* ENUMERAL_TYPE: Types. (line 6)
-* epilogue: Function Entry. (line 6)
-* epilogue instruction pattern: Standard Names. (line 1351)
-* EPILOGUE_USES: Function Entry. (line 152)
-* eq: Comparisons. (line 52)
-* eq and attributes: Expressions. (line 64)
-* eq_attr: Expressions. (line 85)
-* EQ_EXPR: Expression trees. (line 6)
-* equal: Comparisons. (line 52)
-* errno, implicit usage: Library Calls. (line 70)
-* EXACT_DIV_EXPR: Expression trees. (line 6)
-* examining SSA_NAMEs: SSA. (line 218)
-* exception handling <1>: Exception Handling. (line 6)
-* exception handling: Edges. (line 96)
-* exception_receiver instruction pattern: Standard Names. (line 1283)
-* exclamation point: Multi-Alternative. (line 47)
-* exclusion_set: Processor pipeline description.
- (line 215)
-* exclusive-or, bitwise: Arithmetic. (line 163)
-* EXIT_EXPR: Expression trees. (line 6)
-* EXIT_IGNORE_STACK: Function Entry. (line 140)
-* expander definitions: Expander Definitions.
- (line 6)
-* expM2 instruction pattern: Standard Names. (line 497)
-* expr_list: Insns. (line 505)
-* EXPR_STMT: Function Bodies. (line 6)
-* EXPR_STMT_EXPR: Function Bodies. (line 6)
-* expression: Expression trees. (line 6)
-* expression codes: RTL Objects. (line 47)
-* extendMN2 instruction pattern: Standard Names. (line 826)
-* extensible constraints: Simple Constraints. (line 163)
-* EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123)
-* EXTRA_CONSTRAINT: Old Constraints. (line 74)
-* EXTRA_CONSTRAINT_STR: Old Constraints. (line 95)
-* EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100)
-* EXTRA_SPECS: Driver. (line 245)
-* extv instruction pattern: Standard Names. (line 862)
-* extzv instruction pattern: Standard Names. (line 877)
-* F in constraint: Simple Constraints. (line 84)
-* FAIL: Expander Definitions.
- (line 80)
-* fall-thru: Edges. (line 69)
-* 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 202)
-* ffsM2 instruction pattern: Standard Names. (line 611)
-* FIELD_DECL: Declarations. (line 6)
-* file_end_indicate_exec_stack: File Framework. (line 41)
-* files and passes of the compiler: Passes. (line 6)
-* files, generated: Files. (line 6)
-* final_absence_set: Processor pipeline description.
- (line 215)
-* FINAL_PRESCAN_INSN: Instruction Output. (line 46)
-* final_presence_set: Processor pipeline description.
- (line 215)
-* final_scan_insn: Function Entry. (line 181)
-* final_sequence: Instruction Output. (line 117)
-* FIND_BASE_TERM: Addressing Modes. (line 110)
-* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 105)
-* FINI_SECTION_ASM_OP: Sections. (line 90)
-* finite state automaton minimization: Processor pipeline description.
- (line 296)
-* FIRST_PARM_OFFSET: Frame Layout. (line 67)
-* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65)
-* FIRST_PSEUDO_REGISTER: Register Basics. (line 9)
-* FIRST_STACK_REG: Stack Registers. (line 23)
-* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
-* fix: Conversions. (line 66)
-* FIX_TRUNC_EXPR: Expression trees. (line 6)
-* fix_truncMN2 instruction pattern: Standard Names. (line 813)
-* fixed register: Register Basics. (line 15)
-* fixed-point fractional library: Fixed-point fractional library routines.
- (line 6)
-* FIXED_CONVERT_EXPR: Expression trees. (line 6)
-* FIXED_CST: Expression trees. (line 6)
-* FIXED_POINT_TYPE: Types. (line 6)
-* FIXED_REGISTERS: Register Basics. (line 15)
-* fixed_regs: Register Basics. (line 59)
-* fixMN2 instruction pattern: Standard Names. (line 793)
-* FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100)
-* fixuns_truncMN2 instruction pattern: Standard Names. (line 817)
-* fixunsMN2 instruction pattern: Standard Names. (line 802)
-* flags in RTL expression: Flags. (line 6)
-* float: Conversions. (line 58)
-* FLOAT_EXPR: Expression trees. (line 6)
-* float_extend: Conversions. (line 33)
-* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25)
-* FLOAT_STORE_FLAG_VALUE: Misc. (line 301)
-* float_truncate: Conversions. (line 53)
-* FLOAT_TYPE_SIZE: Type Layout. (line 49)
-* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43)
-* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
- (line 226)
-* floating point and cross compilation: Floating Point. (line 6)
-* Floating Point Emulation: Target Fragment. (line 15)
-* floating point emulation library, US Software GOFAST: Library Calls.
- (line 44)
-* floatMN2 instruction pattern: Standard Names. (line 785)
-* floatunsMN2 instruction pattern: Standard Names. (line 789)
-* FLOOR_DIV_EXPR: Expression trees. (line 6)
-* FLOOR_MOD_EXPR: Expression trees. (line 6)
-* floorM2 instruction pattern: Standard Names. (line 532)
-* flow-insensitive alias analysis: Alias analysis. (line 6)
-* flow-sensitive alias analysis: Alias analysis. (line 6)
-* fmodM3 instruction pattern: Standard Names. (line 463)
-* FOR_BODY: Function Bodies. (line 6)
-* FOR_COND: Function Bodies. (line 6)
-* FOR_EXPR: Function Bodies. (line 6)
-* FOR_INIT_STMT: Function Bodies. (line 6)
-* FOR_STMT: Function Bodies. (line 6)
-* FORCE_CODE_SECTION_ALIGN: Sections. (line 136)
-* force_reg: Standard Names. (line 36)
-* fract_convert: Conversions. (line 82)
-* FRACT_TYPE_SIZE: Type Layout. (line 68)
-* fractional types: Fixed-point fractional library routines.
- (line 6)
-* fractMN2 instruction pattern: Standard Names. (line 835)
-* fractunsMN2 instruction pattern: Standard Names. (line 850)
-* frame layout: Frame Layout. (line 6)
-* FRAME_ADDR_RTX: Frame Layout. (line 116)
-* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31)
-* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory.
- (line 69)
-* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212)
-* frame_pointer_needed: Function Entry. (line 34)
-* FRAME_POINTER_REGNUM: Frame Registers. (line 14)
-* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory.
- (line 74)
-* FRAME_POINTER_REQUIRED: Elimination. (line 9)
-* frame_pointer_rtx: Frame Registers. (line 85)
-* frame_related: Flags. (line 242)
-* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags.
- (line 125)
-* frame_related, in mem: Flags. (line 103)
-* frame_related, in reg: Flags. (line 112)
-* frame_related, in symbol_ref: Flags. (line 183)
-* frequency, count, BB_FREQ_BASE: Profile information.
- (line 30)
-* ftruncM2 instruction pattern: Standard Names. (line 808)
-* function: Functions. (line 6)
-* function body: Function Bodies. (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-call insns: Calls. (line 6)
-* FUNCTION_ARG: Register Arguments. (line 11)
-* FUNCTION_ARG_ADVANCE: Register Arguments. (line 185)
-* FUNCTION_ARG_BOUNDARY: Register Arguments. (line 238)
-* FUNCTION_ARG_OFFSET: Register Arguments. (line 196)
-* FUNCTION_ARG_PADDING: Register Arguments. (line 203)
-* FUNCTION_ARG_REGNO_P: Register Arguments. (line 243)
-* FUNCTION_BOUNDARY: Storage Layout. (line 170)
-* FUNCTION_DECL: Functions. (line 6)
-* FUNCTION_INCOMING_ARG: Register Arguments. (line 68)
-* FUNCTION_MODE: Misc. (line 356)
-* FUNCTION_OUTGOING_VALUE: Scalar Return. (line 56)
-* FUNCTION_PROFILER: Profiling. (line 9)
-* FUNCTION_TYPE: Types. (line 6)
-* FUNCTION_VALUE: Scalar Return. (line 52)
-* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 69)
-* functions, leaf: Leaf Functions. (line 6)
-* fundamental type: Types. (line 6)
-* g in constraint: Simple Constraints. (line 110)
-* G in constraint: Simple Constraints. (line 88)
-* garbage collector, invocation: Invoking the garbage collector.
- (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 64)
-* GE_EXPR: Expression trees. (line 6)
-* GEN_ERRNO_RTX: Library Calls. (line 71)
-* gencodes: RTL passes. (line 18)
-* general_operand: Machine-Independent Predicates.
- (line 105)
-* GENERAL_REGS: Register Classes. (line 23)
-* generated files: Files. (line 6)
-* generating assembler output: Output Statement. (line 6)
-* generating insns: RTL Template. (line 6)
-* GENERIC <1>: GENERIC. (line 6)
-* GENERIC <2>: Gimplification pass.
- (line 12)
-* GENERIC: Parsing pass. (line 6)
-* generic predicates: Machine-Independent Predicates.
- (line 6)
-* genflags: RTL passes. (line 18)
-* get_attr: Expressions. (line 80)
-* get_attr_length: Insn Lengths. (line 46)
-* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333)
-* GET_CODE: RTL Objects. (line 47)
-* get_frame_size: Elimination. (line 31)
-* get_insns: Insns. (line 34)
-* get_last_insn: Insns. (line 34)
-* GET_MODE: Machine Modes. (line 280)
-* GET_MODE_ALIGNMENT: Machine Modes. (line 320)
-* GET_MODE_BITSIZE: Machine Modes. (line 304)
-* GET_MODE_CLASS: Machine Modes. (line 294)
-* GET_MODE_FBIT: Machine Modes. (line 311)
-* GET_MODE_IBIT: Machine Modes. (line 307)
-* GET_MODE_MASK: Machine Modes. (line 315)
-* GET_MODE_NAME: Machine Modes. (line 291)
-* GET_MODE_NUNITS: Machine Modes. (line 329)
-* GET_MODE_SIZE: Machine Modes. (line 301)
-* GET_MODE_UNIT_SIZE: Machine Modes. (line 323)
-* GET_MODE_WIDER_MODE: Machine Modes. (line 297)
-* GET_RTX_CLASS: RTL Classes. (line 6)
-* GET_RTX_FORMAT: RTL Classes. (line 130)
-* GET_RTX_LENGTH: RTL Classes. (line 127)
-* geu: Comparisons. (line 72)
-* geu and attributes: Expressions. (line 64)
-* GGC: Type Information. (line 6)
-* ggc_collect: Invoking the garbage collector.
- (line 6)
-* GIMPLE <1>: GIMPLE. (line 6)
-* GIMPLE <2>: Gimplification pass.
- (line 6)
-* GIMPLE: Parsing pass. (line 14)
-* GIMPLE Exception Handling: GIMPLE Exception Handling.
- (line 6)
-* GIMPLE instruction set: GIMPLE instruction set.
- (line 6)
-* GIMPLE sequences: GIMPLE sequences. (line 6)
-* gimple_addresses_taken: Manipulating GIMPLE statements.
- (line 90)
-* GIMPLE_ASM: GIMPLE_ASM. (line 6)
-* gimple_asm_clear_volatile: GIMPLE_ASM. (line 63)
-* gimple_asm_clobber_op: GIMPLE_ASM. (line 46)
-* gimple_asm_input_op: GIMPLE_ASM. (line 30)
-* gimple_asm_output_op: GIMPLE_ASM. (line 38)
-* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50)
-* gimple_asm_set_input_op: GIMPLE_ASM. (line 34)
-* gimple_asm_set_output_op: GIMPLE_ASM. (line 42)
-* gimple_asm_set_volatile: GIMPLE_ASM. (line 60)
-* gimple_asm_volatile_p: GIMPLE_ASM. (line 57)
-* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6)
-* gimple_assign_cast_p: GIMPLE_ASSIGN. (line 89)
-* gimple_assign_lhs: GIMPLE_ASSIGN. (line 51)
-* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57)
-* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64)
-* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 71)
-* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 74)
-* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85)
-* gimple_bb: Manipulating GIMPLE statements.
- (line 18)
-* GIMPLE_BIND: GIMPLE_BIND. (line 6)
-* gimple_bind_add_seq: GIMPLE_BIND. (line 36)
-* gimple_bind_add_stmt: GIMPLE_BIND. (line 32)
-* gimple_bind_append_vars: GIMPLE_BIND. (line 19)
-* gimple_bind_block: GIMPLE_BIND. (line 40)
-* gimple_bind_body: GIMPLE_BIND. (line 23)
-* gimple_bind_set_block: GIMPLE_BIND. (line 45)
-* gimple_bind_set_body: GIMPLE_BIND. (line 28)
-* gimple_bind_set_vars: GIMPLE_BIND. (line 15)
-* gimple_bind_vars: GIMPLE_BIND. (line 12)
-* gimple_block: Manipulating GIMPLE statements.
- (line 21)
-* gimple_build_asm: GIMPLE_ASM. (line 8)
-* gimple_build_asm_vec: GIMPLE_ASM. (line 17)
-* gimple_build_assign: GIMPLE_ASSIGN. (line 7)
-* gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30)
-* gimple_build_bind: GIMPLE_BIND. (line 8)
-* gimple_build_call: GIMPLE_CALL. (line 8)
-* gimple_build_call_from_tree: GIMPLE_CALL. (line 16)
-* gimple_build_call_vec: GIMPLE_CALL. (line 25)
-* gimple_build_catch: GIMPLE_CATCH. (line 8)
-* gimple_build_cdt: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 7)
-* gimple_build_cond: GIMPLE_COND. (line 8)
-* gimple_build_cond_from_tree: GIMPLE_COND. (line 16)
-* gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8)
-* gimple_build_goto: GIMPLE_LABEL. (line 18)
-* gimple_build_label: GIMPLE_LABEL. (line 7)
-* gimple_build_nop: GIMPLE_NOP. (line 7)
-* gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD.
- (line 8)
-* gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE.
- (line 7)
-* gimple_build_omp_continue: GIMPLE_OMP_CONTINUE.
- (line 8)
-* gimple_build_omp_critical: GIMPLE_OMP_CRITICAL.
- (line 8)
-* gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9)
-* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7)
-* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7)
-* gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL.
- (line 8)
-* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7)
-* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7)
-* gimple_build_omp_sections: GIMPLE_OMP_SECTIONS.
- (line 8)
-* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS.
- (line 14)
-* gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8)
-* gimple_build_resx: GIMPLE_RESX. (line 7)
-* gimple_build_return: GIMPLE_RETURN. (line 7)
-* gimple_build_switch: GIMPLE_SWITCH. (line 8)
-* gimple_build_switch_vec: GIMPLE_SWITCH. (line 16)
-* gimple_build_try: GIMPLE_TRY. (line 8)
-* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR.
- (line 7)
-* GIMPLE_CALL: GIMPLE_CALL. (line 6)
-* gimple_call_arg: GIMPLE_CALL. (line 66)
-* gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91)
-* gimple_call_chain: GIMPLE_CALL. (line 57)
-* gimple_call_copy_skip_args: GIMPLE_CALL. (line 98)
-* gimple_call_fn: GIMPLE_CALL. (line 38)
-* gimple_call_fndecl: GIMPLE_CALL. (line 46)
-* gimple_call_lhs: GIMPLE_CALL. (line 29)
-* gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88)
-* gimple_call_noreturn_p: GIMPLE_CALL. (line 94)
-* gimple_call_return_type: GIMPLE_CALL. (line 54)
-* gimple_call_set_arg: GIMPLE_CALL. (line 76)
-* gimple_call_set_chain: GIMPLE_CALL. (line 60)
-* gimple_call_set_fn: GIMPLE_CALL. (line 42)
-* gimple_call_set_fndecl: GIMPLE_CALL. (line 51)
-* gimple_call_set_lhs: GIMPLE_CALL. (line 35)
-* gimple_call_set_tail: GIMPLE_CALL. (line 80)
-* gimple_call_tail_p: GIMPLE_CALL. (line 85)
-* GIMPLE_CATCH: GIMPLE_CATCH. (line 6)
-* gimple_catch_handler: GIMPLE_CATCH. (line 20)
-* gimple_catch_set_handler: GIMPLE_CATCH. (line 28)
-* gimple_catch_set_types: GIMPLE_CATCH. (line 24)
-* gimple_catch_types: GIMPLE_CATCH. (line 13)
-* gimple_cdt_location: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 24)
-* gimple_cdt_new_type: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 11)
-* gimple_cdt_set_location: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 32)
-* gimple_cdt_set_new_type: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 20)
-* GIMPLE_CHANGE_DYNAMIC_TYPE: GIMPLE_CHANGE_DYNAMIC_TYPE.
- (line 6)
-* gimple_code: Manipulating GIMPLE statements.
- (line 15)
-* GIMPLE_COND: GIMPLE_COND. (line 6)
-* gimple_cond_false_label: GIMPLE_COND. (line 60)
-* gimple_cond_lhs: GIMPLE_COND. (line 30)
-* gimple_cond_make_false: GIMPLE_COND. (line 64)
-* gimple_cond_make_true: GIMPLE_COND. (line 67)
-* gimple_cond_rhs: GIMPLE_COND. (line 38)
-* gimple_cond_set_code: GIMPLE_COND. (line 26)
-* gimple_cond_set_false_label: GIMPLE_COND. (line 56)
-* gimple_cond_set_lhs: GIMPLE_COND. (line 34)
-* gimple_cond_set_rhs: GIMPLE_COND. (line 42)
-* gimple_cond_set_true_label: GIMPLE_COND. (line 51)
-* gimple_cond_true_label: GIMPLE_COND. (line 46)
-* gimple_copy: Manipulating GIMPLE statements.
- (line 147)
-* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6)
-* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19)
-* gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33)
-* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29)
-* gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37)
-* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24)
-* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12)
-* gimple_expr_type: Manipulating GIMPLE statements.
- (line 24)
-* gimple_goto_dest: GIMPLE_LABEL. (line 21)
-* gimple_goto_set_dest: GIMPLE_LABEL. (line 24)
-* gimple_has_mem_ops: Manipulating GIMPLE statements.
- (line 72)
-* gimple_has_ops: Manipulating GIMPLE statements.
- (line 69)
-* gimple_has_volatile_ops: Manipulating GIMPLE statements.
- (line 134)
-* GIMPLE_LABEL: GIMPLE_LABEL. (line 6)
-* gimple_label_label: GIMPLE_LABEL. (line 11)
-* gimple_label_set_label: GIMPLE_LABEL. (line 14)
-* gimple_loaded_syms: Manipulating GIMPLE statements.
- (line 122)
-* gimple_locus: Manipulating GIMPLE statements.
- (line 42)
-* gimple_locus_empty_p: Manipulating GIMPLE statements.
- (line 48)
-* gimple_modified_p: Manipulating GIMPLE statements.
- (line 130)
-* gimple_no_warning_p: Manipulating GIMPLE statements.
- (line 51)
-* GIMPLE_NOP: GIMPLE_NOP. (line 6)
-* gimple_nop_p: GIMPLE_NOP. (line 10)
-* gimple_num_ops <1>: Manipulating GIMPLE statements.
- (line 75)
-* gimple_num_ops: Logical Operators. (line 76)
-* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD.
- (line 6)
-* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 17)
-* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 24)
-* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 14)
-* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 21)
-* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE.
- (line 6)
-* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE.
- (line 12)
-* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE.
- (line 15)
-* gimple_omp_body: GIMPLE_OMP_PARALLEL.
- (line 24)
-* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE.
- (line 6)
-* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE.
- (line 13)
-* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE.
- (line 17)
-* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE.
- (line 24)
-* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE.
- (line 28)
-* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE.
- (line 20)
-* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE.
- (line 31)
-* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL.
- (line 6)
-* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL.
- (line 13)
-* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL.
- (line 21)
-* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6)
-* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20)
-* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51)
-* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61)
-* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31)
-* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41)
-* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70)
-* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27)
-* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80)
-* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58)
-* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67)
-* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38)
-* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48)
-* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75)
-* 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 42)
-* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL.
- (line 31)
-* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL.
- (line 16)
-* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL.
- (line 54)
-* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL.
- (line 51)
-* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL.
- (line 38)
-* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL.
- (line 20)
-* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL.
- (line 62)
-* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6)
-* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14)
-* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11)
-* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6)
-* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12)
-* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16)
-* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS.
- (line 6)
-* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS.
- (line 30)
-* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS.
- (line 17)
-* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS.
- (line 37)
-* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS.
- (line 26)
-* gimple_omp_set_body: GIMPLE_OMP_PARALLEL.
- (line 28)
-* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6)
-* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14)
-* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21)
-* gimple_op <1>: Manipulating GIMPLE statements.
- (line 81)
-* gimple_op: Logical Operators. (line 79)
-* GIMPLE_PHI: GIMPLE_PHI. (line 6)
-* gimple_phi_capacity: GIMPLE_PHI. (line 10)
-* gimple_phi_num_args: GIMPLE_PHI. (line 14)
-* gimple_phi_result: GIMPLE_PHI. (line 19)
-* gimple_phi_set_arg: GIMPLE_PHI. (line 33)
-* gimple_phi_set_result: GIMPLE_PHI. (line 25)
-* GIMPLE_RESX: GIMPLE_RESX. (line 6)
-* gimple_resx_region: GIMPLE_RESX. (line 13)
-* gimple_resx_set_region: GIMPLE_RESX. (line 16)
-* GIMPLE_RETURN: GIMPLE_RETURN. (line 6)
-* gimple_return_retval: GIMPLE_RETURN. (line 10)
-* gimple_return_set_retval: GIMPLE_RETURN. (line 14)
-* gimple_rhs_class: GIMPLE_ASSIGN. (line 46)
-* gimple_seq_add_seq: GIMPLE sequences. (line 32)
-* gimple_seq_add_stmt: GIMPLE sequences. (line 26)
-* gimple_seq_alloc: GIMPLE sequences. (line 62)
-* gimple_seq_copy: GIMPLE sequences. (line 67)
-* gimple_seq_deep_copy: GIMPLE sequences. (line 37)
-* gimple_seq_empty_p: GIMPLE sequences. (line 70)
-* gimple_seq_first: GIMPLE sequences. (line 44)
-* gimple_seq_init: GIMPLE sequences. (line 59)
-* gimple_seq_last: GIMPLE sequences. (line 47)
-* gimple_seq_reverse: GIMPLE sequences. (line 40)
-* gimple_seq_set_first: GIMPLE sequences. (line 55)
-* gimple_seq_set_last: GIMPLE sequences. (line 51)
-* gimple_seq_singleton_p: GIMPLE sequences. (line 79)
-* gimple_set_block: Manipulating GIMPLE statements.
- (line 39)
-* gimple_set_def_ops: Manipulating GIMPLE statements.
- (line 98)
-* gimple_set_has_volatile_ops: Manipulating GIMPLE statements.
- (line 138)
-* gimple_set_locus: Manipulating GIMPLE statements.
- (line 45)
-* gimple_set_op: Manipulating GIMPLE statements.
- (line 87)
-* gimple_set_plf: Manipulating GIMPLE statements.
- (line 62)
-* gimple_set_use_ops: Manipulating GIMPLE statements.
- (line 105)
-* gimple_set_vdef_ops: Manipulating GIMPLE statements.
- (line 119)
-* gimple_set_visited: Manipulating GIMPLE statements.
- (line 55)
-* gimple_set_vuse_ops: Manipulating GIMPLE statements.
- (line 112)
-* gimple_statement_base: Tuple representation.
- (line 14)
-* gimple_statement_with_ops: Tuple representation.
- (line 96)
-* gimple_stored_syms: Manipulating GIMPLE statements.
- (line 126)
-* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6)
-* gimple_switch_default_label: GIMPLE_SWITCH. (line 46)
-* gimple_switch_index: GIMPLE_SWITCH. (line 31)
-* gimple_switch_label: GIMPLE_SWITCH. (line 37)
-* gimple_switch_num_labels: GIMPLE_SWITCH. (line 22)
-* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 50)
-* gimple_switch_set_index: GIMPLE_SWITCH. (line 34)
-* gimple_switch_set_label: GIMPLE_SWITCH. (line 42)
-* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 27)
-* GIMPLE_TRY: GIMPLE_TRY. (line 6)
-* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20)
-* gimple_try_cleanup: GIMPLE_TRY. (line 27)
-* gimple_try_eval: GIMPLE_TRY. (line 23)
-* gimple_try_flags: GIMPLE_TRY. (line 16)
-* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32)
-* gimple_try_set_cleanup: GIMPLE_TRY. (line 41)
-* gimple_try_set_eval: GIMPLE_TRY. (line 36)
-* gimple_visited_p: Manipulating GIMPLE statements.
- (line 58)
-* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
- (line 11)
-* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
- (line 18)
-* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
- (line 15)
-* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
- (line 22)
-* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR.
- (line 6)
-* gimplification <1>: Gimplification pass.
- (line 6)
-* gimplification: Parsing pass. (line 14)
-* gimplifier: Parsing pass. (line 14)
-* gimplify_assign: GIMPLE_ASSIGN. (line 19)
-* gimplify_expr: Gimplification pass.
- (line 18)
-* gimplify_function_tree: Gimplification pass.
- (line 18)
-* GLOBAL_INIT_PRIORITY: Function Basics. (line 6)
-* global_regs: Register Basics. (line 59)
-* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48)
-* GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 190)
-* GOFAST, floating point emulation library: Library Calls. (line 44)
-* gofast_maybe_init_libfuncs: Library Calls. (line 44)
-* greater than: Comparisons. (line 60)
-* gsi_after_labels: Sequence iterators. (line 76)
-* gsi_bb: Sequence iterators. (line 83)
-* gsi_commit_edge_inserts: Sequence iterators. (line 194)
-* gsi_commit_one_edge_insert: Sequence iterators. (line 190)
-* gsi_end_p: Sequence iterators. (line 60)
-* gsi_for_stmt: Sequence iterators. (line 157)
-* gsi_insert_after: Sequence iterators. (line 147)
-* gsi_insert_before: Sequence iterators. (line 136)
-* gsi_insert_on_edge: Sequence iterators. (line 174)
-* gsi_insert_on_edge_immediate: Sequence iterators. (line 185)
-* gsi_insert_seq_after: Sequence iterators. (line 154)
-* gsi_insert_seq_before: Sequence iterators. (line 143)
-* gsi_insert_seq_on_edge: Sequence iterators. (line 179)
-* gsi_last: Sequence iterators. (line 50)
-* gsi_last_bb: Sequence iterators. (line 56)
-* gsi_link_after: Sequence iterators. (line 115)
-* gsi_link_before: Sequence iterators. (line 105)
-* gsi_link_seq_after: Sequence iterators. (line 110)
-* gsi_link_seq_before: Sequence iterators. (line 99)
-* gsi_move_after: Sequence iterators. (line 161)
-* gsi_move_before: Sequence iterators. (line 166)
-* gsi_move_to_bb_end: Sequence iterators. (line 171)
-* gsi_next: Sequence iterators. (line 66)
-* gsi_one_before_end_p: Sequence iterators. (line 63)
-* gsi_prev: Sequence iterators. (line 69)
-* gsi_remove: Sequence iterators. (line 90)
-* gsi_replace: Sequence iterators. (line 130)
-* gsi_seq: Sequence iterators. (line 86)
-* gsi_split_seq_after: Sequence iterators. (line 120)
-* gsi_split_seq_before: Sequence iterators. (line 125)
-* gsi_start: Sequence iterators. (line 40)
-* gsi_start_bb: Sequence iterators. (line 46)
-* gsi_stmt: Sequence iterators. (line 72)
-* gt: Comparisons. (line 60)
-* gt and attributes: Expressions. (line 64)
-* GT_EXPR: Expression trees. (line 6)
-* gtu: Comparisons. (line 64)
-* gtu and attributes: Expressions. (line 64)
-* GTY: Type Information. (line 6)
-* H in constraint: Simple Constraints. (line 88)
-* HAmode: Machine Modes. (line 144)
-* HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 467)
-* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 478)
-* HANDLE_SYSV_PRAGMA: Misc. (line 438)
-* HANDLER: Function Bodies. (line 6)
-* HANDLER_BODY: Function Bodies. (line 6)
-* HANDLER_PARMS: Function Bodies. (line 6)
-* hard registers: Regs and Memory. (line 9)
-* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20)
-* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53)
-* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20)
-* HARD_REGNO_MODE_OK: Values in Registers.
- (line 58)
-* HARD_REGNO_NREGS: Values in Registers.
- (line 11)
-* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers.
- (line 25)
-* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers.
- (line 43)
-* HARD_REGNO_RENAME_OK: Values in Registers.
- (line 119)
-* HAS_INIT_SECTION: Macros for Initialization.
- (line 19)
-* HAS_LONG_COND_BRANCH: Misc. (line 9)
-* HAS_LONG_UNCOND_BRANCH: Misc. (line 18)
-* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11)
-* HAVE_POST_DECREMENT: Addressing Modes. (line 12)
-* HAVE_POST_INCREMENT: Addressing Modes. (line 11)
-* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18)
-* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24)
-* HAVE_PRE_DECREMENT: Addressing Modes. (line 10)
-* HAVE_PRE_INCREMENT: Addressing Modes. (line 9)
-* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17)
-* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23)
-* HCmode: Machine Modes. (line 197)
-* HFmode: Machine Modes. (line 58)
-* high: Constants. (line 109)
-* HImode: Machine Modes. (line 29)
-* HImode, in insn: Insns. (line 231)
-* 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 12)
-* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45)
-* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26)
-* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89)
-* HOST_LONG_LONG_FORMAT: Host Misc. (line 41)
-* HOST_OBJECT_SUFFIX: Filesystem. (line 40)
-* HOST_WIDE_INT: Anchored Addresses. (line 33)
-* HOT_TEXT_SECTION_NAME: Sections. (line 43)
-* HQmode: Machine Modes. (line 107)
-* I in constraint: Simple Constraints. (line 71)
-* i in constraint: Simple Constraints. (line 60)
-* identifier: Identifiers. (line 6)
-* IDENTIFIER_LENGTH: Identifiers. (line 20)
-* IDENTIFIER_NODE: Identifiers. (line 6)
-* IDENTIFIER_OPNAME_P: Identifiers. (line 25)
-* IDENTIFIER_POINTER: Identifiers. (line 15)
-* IDENTIFIER_TYPENAME_P: Identifiers. (line 31)
-* IEEE 754-2008: Decimal float library routines.
- (line 6)
-* IF_COND: Function Bodies. (line 6)
-* if_marked: GTY Options. (line 155)
-* IF_STMT: Function Bodies. (line 6)
-* if_then_else: Comparisons. (line 80)
-* if_then_else and attributes: Expressions. (line 32)
-* if_then_else usage: Side Effects. (line 56)
-* IFCVT_EXTRA_FIELDS: Misc. (line 619)
-* IFCVT_INIT_EXTRA_FIELDS: Misc. (line 614)
-* IFCVT_MODIFY_CANCEL: Misc. (line 608)
-* IFCVT_MODIFY_FINAL: Misc. (line 602)
-* IFCVT_MODIFY_INSN: Misc. (line 596)
-* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 589)
-* IFCVT_MODIFY_TESTS: Misc. (line 578)
-* IMAGPART_EXPR: Expression trees. (line 6)
-* Immediate Uses: SSA Operands. (line 274)
-* immediate_operand: Machine-Independent Predicates.
- (line 11)
-* IMMEDIATE_PREFIX: Instruction Output. (line 127)
-* in_struct: Flags. (line 258)
-* 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, jump_insn and call_insn: Flags. (line 166)
-* in_struct, in mem: Flags. (line 70)
-* in_struct, in subreg: Flags. (line 205)
-* include: Including Patterns. (line 6)
-* INCLUDE_DEFAULTS: Driver. (line 430)
-* inclusive-or, bitwise: Arithmetic. (line 158)
-* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183)
-* INCOMING_REGNO: Register Basics. (line 91)
-* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139)
-* INCOMING_STACK_BOUNDARY: Storage Layout. (line 165)
-* INDEX_REG_CLASS: Register Classes. (line 134)
-* indirect_jump instruction pattern: Standard Names. (line 1078)
-* indirect_operand: Machine-Independent Predicates.
- (line 71)
-* INDIRECT_REF: Expression trees. (line 6)
-* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 98)
-* INIT_CUMULATIVE_ARGS: Register Arguments. (line 149)
-* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 176)
-* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 170)
-* INIT_ENVIRONMENT: Driver. (line 369)
-* INIT_EXPANDERS: Per-Function Data. (line 39)
-* INIT_EXPR: Expression trees. (line 6)
-* init_machine_status: Per-Function Data. (line 45)
-* init_one_libfunc: Library Calls. (line 15)
-* INIT_SECTION_ASM_OP <1>: Macros for Initialization.
- (line 10)
-* INIT_SECTION_ASM_OP: Sections. (line 82)
-* INITIAL_ELIMINATION_OFFSET: Elimination. (line 79)
-* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83)
-* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32)
-* initialization routines: Initialization. (line 6)
-* INITIALIZE_TRAMPOLINE: Trampolines. (line 55)
-* inlining: Target Attributes. (line 86)
-* insert_insn_on_edge: Maintaining the CFG.
- (line 118)
-* insn: Insns. (line 63)
-* insn and /f: Flags. (line 125)
-* insn and /j: Flags. (line 175)
-* insn and /s: Flags. (line 49)
-* 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 splitting: Insn Splitting. (line 6)
-* insn-attr.h: Defining Attributes.
- (line 24)
-* INSN_ANNULLED_BRANCH_P: Flags. (line 39)
-* INSN_CODE: Insns. (line 257)
-* INSN_DELETED_P: Flags. (line 44)
-* INSN_FROM_TARGET_P: Flags. (line 49)
-* insn_list: Insns. (line 505)
-* INSN_REFERENCES_ARE_DELAYED: Misc. (line 517)
-* INSN_SETS_ARE_DELAYED: Misc. (line 506)
-* INSN_UID: Insns. (line 23)
-* insns: Insns. (line 6)
-* insns, generating: RTL Template. (line 6)
-* insns, recognizing: RTL Template. (line 6)
-* instruction attributes: Insn Attributes. (line 6)
-* instruction latency time: Processor pipeline description.
- (line 6)
-* instruction patterns: Patterns. (line 6)
-* instruction splitting: Insn Splitting. (line 6)
-* insv instruction pattern: Standard Names. (line 880)
-* int <1>: Run-time Target. (line 56)
-* int: Manipulating GIMPLE statements.
- (line 66)
-* INT_TYPE_SIZE: Type Layout. (line 12)
-* INTEGER_CST: Expression trees. (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 14)
-* INTMAX_TYPE: Type Layout. (line 213)
-* introduction: Top. (line 6)
-* INVOKE__main: Macros for Initialization.
- (line 51)
-* ior: Arithmetic. (line 158)
-* ior and attributes: Expressions. (line 50)
-* ior, canonicalization of: Insn Canonicalizations.
- (line 57)
-* iorM3 instruction pattern: Standard Names. (line 222)
-* IRA_COVER_CLASSES: Register Classes. (line 516)
-* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 37)
-* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120)
-* is_gimple_omp: GIMPLE_OMP_PARALLEL.
- (line 65)
-* iterators in .md files: Iterators. (line 6)
-* IV analysis on GIMPLE: Scalar evolutions. (line 6)
-* IV analysis on RTL: loop-iv. (line 6)
-* jump: Flags. (line 309)
-* jump instruction pattern: Standard Names. (line 969)
-* jump instruction patterns: Jump Patterns. (line 6)
-* jump instructions and set: Side Effects. (line 56)
-* jump, in call_insn: Flags. (line 179)
-* jump, in insn: Flags. (line 175)
-* jump, in mem: Flags. (line 79)
-* JUMP_ALIGN: Alignment Output. (line 9)
-* jump_insn: Insns. (line 73)
-* jump_insn and /f: Flags. (line 125)
-* jump_insn and /s: Flags. (line 49)
-* 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 142)
-* Jumps: Jumps. (line 6)
-* LABEL_ALIGN: Alignment Output. (line 52)
-* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22)
-* LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30)
-* LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62)
-* LABEL_ALT_ENTRY_P: Insns. (line 140)
-* LABEL_ALTERNATE_NAME: Edges. (line 180)
-* LABEL_DECL: Declarations. (line 6)
-* LABEL_KIND: Insns. (line 140)
-* LABEL_NUSES: Insns. (line 136)
-* LABEL_PRESERVE_P: Flags. (line 59)
-* label_ref: Constants. (line 86)
-* label_ref and /v: Flags. (line 65)
-* label_ref, RTL sharing: Sharing. (line 35)
-* LABEL_REF_NONLOCAL_P: Flags. (line 65)
-* lang_hooks.gimplify_expr: Gimplification pass.
- (line 18)
-* lang_hooks.parse_file: Parsing pass. (line 6)
-* language-independent intermediate representation: Parsing pass.
- (line 14)
-* large return values: Aggregate Return. (line 6)
-* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 469)
-* LAST_STACK_REG: Stack Registers. (line 27)
-* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
-* lceilMN2: Standard Names. (line 597)
-* LCSSA: LCSSA. (line 6)
-* LD_FINI_SWITCH: Macros for Initialization.
- (line 29)
-* LD_INIT_SWITCH: Macros for Initialization.
- (line 25)
-* LDD_SUFFIX: Macros for Initialization.
- (line 116)
-* le: Comparisons. (line 76)
-* le and attributes: Expressions. (line 64)
-* LE_EXPR: Expression trees. (line 6)
-* leaf functions: Leaf Functions. (line 6)
-* leaf_function_p: Standard Names. (line 1040)
-* LEAF_REG_REMAP: Leaf Functions. (line 39)
-* LEAF_REGISTERS: Leaf Functions. (line 25)
-* left rotate: Arithmetic. (line 190)
-* left shift: Arithmetic. (line 168)
-* LEGITIMATE_CONSTANT_P: Addressing Modes. (line 205)
-* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31)
-* LEGITIMIZE_ADDRESS: Addressing Modes. (line 122)
-* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 145)
-* length: GTY Options. (line 50)
-* less than: Comparisons. (line 68)
-* less than or equal: Comparisons. (line 76)
-* leu: Comparisons. (line 76)
-* leu and attributes: Expressions. (line 64)
-* lfloorMN2: Standard Names. (line 592)
-* LIB2FUNCS_EXTRA: Target Fragment. (line 11)
-* LIB_SPEC: Driver. (line 170)
-* LIBCALL_VALUE: Scalar Return. (line 60)
-* libgcc.a: Library Calls. (line 6)
-* LIBGCC2_CFLAGS: Target Fragment. (line 8)
-* LIBGCC2_HAS_DF_MODE: Type Layout. (line 109)
-* LIBGCC2_HAS_TF_MODE: Type Layout. (line 123)
-* LIBGCC2_HAS_XF_MODE: Type Layout. (line 117)
-* LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103)
-* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 929)
-* LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36)
-* LIBGCC_SPEC: Driver. (line 178)
-* library subroutine names: Library Calls. (line 6)
-* LIBRARY_PATH_ENV: Misc. (line 557)
-* LIMIT_RELOAD_CLASS: Register Classes. (line 239)
-* Linear loop transformations framework: Lambda. (line 6)
-* LINK_COMMAND_SPEC: Driver. (line 299)
-* LINK_EH_SPEC: Driver. (line 205)
-* LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309)
-* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295)
-* LINK_LIBGCC_SPECIAL_1: Driver. (line 290)
-* LINK_SPEC: Driver. (line 163)
-* linkage: Function Basics. (line 6)
-* list: Containers. (line 6)
-* Liveness representation: Liveness information.
- (line 6)
-* lo_sum: Arithmetic. (line 24)
-* load address instruction: Simple Constraints. (line 154)
-* LOAD_EXTEND_OP: Misc. (line 69)
-* load_multiple instruction pattern: Standard Names. (line 137)
-* LOCAL_ALIGNMENT: Storage Layout. (line 254)
-* LOCAL_CLASS_P: Classes. (line 68)
-* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 278)
-* LOCAL_INCLUDE_DIR: Driver. (line 376)
-* LOCAL_LABEL_PREFIX: Instruction Output. (line 125)
-* LOCAL_REGNO: Register Basics. (line 105)
-* LOG_LINKS: Insns. (line 276)
-* Logical Operators: Logical Operators. (line 6)
-* logical-and, bitwise: Arithmetic. (line 153)
-* logM2 instruction pattern: Standard Names. (line 505)
-* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93)
-* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58)
-* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73)
-* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98)
-* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78)
-* LONG_LONG_TYPE_SIZE: Type Layout. (line 33)
-* LONG_TYPE_SIZE: Type Layout. (line 22)
-* longjmp and automatic variables: Interface. (line 52)
-* 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)
-* LOOP_ALIGN: Alignment Output. (line 35)
-* LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48)
-* LOOP_EXPR: Expression trees. (line 6)
-* looping instruction patterns: Looping Patterns. (line 6)
-* lowering, language-dependent intermediate representation: Parsing pass.
- (line 14)
-* lrintMN2: Standard Names. (line 582)
-* lroundMN2: Standard Names. (line 587)
-* LSHIFT_EXPR: Expression trees. (line 6)
-* lshiftrt: Arithmetic. (line 185)
-* lshiftrt and attributes: Expressions. (line 64)
-* lshrM3 instruction pattern: Standard Names. (line 441)
-* lt: Comparisons. (line 68)
-* lt and attributes: Expressions. (line 64)
-* LT_EXPR: Expression trees. (line 6)
-* LTGT_EXPR: Expression trees. (line 6)
-* ltu: Comparisons. (line 68)
-* 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)
-* machine_mode: Condition Code. (line 157)
-* macros, target description: Target Macros. (line 6)
-* maddMN4 instruction pattern: Standard Names. (line 364)
-* MAKE_DECL_ONE_ONLY: Label Output. (line 218)
-* make_phi_node: GIMPLE_PHI. (line 7)
-* make_safe_from: Expander Definitions.
- (line 148)
-* makefile fragment: Fragments. (line 6)
-* makefile targets: Makefile. (line 6)
-* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 179)
-* Manipulating GIMPLE statements: Manipulating GIMPLE statements.
- (line 6)
-* mark_hook: GTY Options. (line 170)
-* marking roots: GGC Roots. (line 6)
-* MASK_RETURN_ADDR: Exception Region Output.
- (line 35)
-* match_dup <1>: define_peephole2. (line 28)
-* match_dup: RTL Template. (line 73)
-* match_dup and attributes: Insn Lengths. (line 16)
-* match_op_dup: RTL Template. (line 163)
-* match_operand: RTL Template. (line 16)
-* match_operand and attributes: Expressions. (line 55)
-* match_operator: RTL Template. (line 95)
-* match_par_dup: RTL Template. (line 219)
-* match_parallel: RTL Template. (line 172)
-* match_scratch <1>: define_peephole2. (line 28)
-* match_scratch: RTL Template. (line 58)
-* matching constraint: Simple Constraints. (line 132)
-* matching operands: Output Template. (line 49)
-* math library: Soft float library routines.
- (line 6)
-* math, in RTL: Arithmetic. (line 6)
-* MATH_LIBRARY: Misc. (line 550)
-* matherr: Library Calls. (line 58)
-* MAX_BITS_PER_WORD: Storage Layout. (line 61)
-* MAX_CONDITIONAL_EXECUTE: Misc. (line 572)
-* MAX_FIXED_MODE_SIZE: Storage Layout. (line 420)
-* MAX_MOVE_MAX: Misc. (line 120)
-* MAX_OFILE_ALIGNMENT: Storage Layout. (line 216)
-* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42)
-* MAX_STACK_ALIGNMENT: Storage Layout. (line 209)
-* maxM3 instruction pattern: Standard Names. (line 234)
-* may_trap_p, tree_could_trap_p: Edges. (line 115)
-* maybe_undef: GTY Options. (line 178)
-* mcount: Profiling. (line 12)
-* MD_CAN_REDIRECT_BRANCH: Misc. (line 697)
-* MD_EXEC_PREFIX: Driver. (line 330)
-* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98)
-* MD_HANDLE_UNWABI: Exception Handling. (line 118)
-* MD_STARTFILE_PREFIX: Driver. (line 358)
-* MD_STARTFILE_PREFIX_1: Driver. (line 364)
-* MD_UNWIND_SUPPORT: Exception Handling. (line 94)
-* mem: Regs and Memory. (line 374)
-* mem and /c: Flags. (line 99)
-* mem and /f: Flags. (line 103)
-* mem and /i: Flags. (line 85)
-* mem and /j: Flags. (line 79)
-* mem and /s: Flags. (line 70)
-* mem and /u: Flags. (line 152)
-* mem and /v: Flags. (line 94)
-* mem, RTL sharing: Sharing. (line 40)
-* MEM_ALIAS_SET: Special Accessors. (line 9)
-* MEM_ALIGN: Special Accessors. (line 36)
-* MEM_EXPR: Special Accessors. (line 20)
-* MEM_IN_STRUCT_P: Flags. (line 70)
-* MEM_KEEP_ALIAS_SET_P: Flags. (line 79)
-* MEM_NOTRAP_P: Flags. (line 99)
-* MEM_OFFSET: Special Accessors. (line 28)
-* MEM_POINTER: Flags. (line 103)
-* MEM_READONLY_P: Flags. (line 152)
-* MEM_SCALAR_P: Flags. (line 85)
-* MEM_SIZE: Special Accessors. (line 31)
-* MEM_VOLATILE_P: Flags. (line 94)
-* MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 400)
-* memory reference, nonoffsettable: Simple Constraints. (line 246)
-* memory references in constraints: Simple Constraints. (line 17)
-* memory_barrier instruction pattern: Standard Names. (line 1413)
-* MEMORY_MOVE_COST: Costs. (line 29)
-* memory_operand: Machine-Independent Predicates.
- (line 58)
-* METHOD_TYPE: Types. (line 6)
-* MIN_UNITS_PER_WORD: Storage Layout. (line 71)
-* MINIMUM_ALIGNMENT: Storage Layout. (line 288)
-* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 187)
-* minM3 instruction pattern: Standard Names. (line 234)
-* minus: Arithmetic. (line 36)
-* minus and attributes: Expressions. (line 64)
-* minus, canonicalization of: Insn Canonicalizations.
- (line 27)
-* MINUS_EXPR: Expression trees. (line 6)
-* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6)
-* mod: Arithmetic. (line 131)
-* mod and attributes: Expressions. (line 64)
-* mode classes: Machine Modes. (line 219)
-* mode iterators in .md files: Mode Iterators. (line 6)
-* mode switching: Mode Switching. (line 6)
-* MODE_ACCUM: Machine Modes. (line 249)
-* MODE_AFTER: Mode Switching. (line 49)
-* MODE_BASE_REG_CLASS: Register Classes. (line 112)
-* MODE_BASE_REG_REG_CLASS: Register Classes. (line 118)
-* MODE_CC: Machine Modes. (line 268)
-* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 125)
-* MODE_COMPLEX_FLOAT: Machine Modes. (line 260)
-* MODE_COMPLEX_INT: Machine Modes. (line 257)
-* MODE_DECIMAL_FLOAT: Machine Modes. (line 237)
-* MODE_ENTRY: Mode Switching. (line 54)
-* MODE_EXIT: Mode Switching. (line 60)
-* MODE_FLOAT: Machine Modes. (line 233)
-* MODE_FRACT: Machine Modes. (line 241)
-* MODE_FUNCTION: Machine Modes. (line 264)
-* MODE_INT: Machine Modes. (line 225)
-* MODE_NEEDED: Mode Switching. (line 42)
-* MODE_PARTIAL_INT: Machine Modes. (line 229)
-* MODE_PRIORITY_TO_MODE: Mode Switching. (line 66)
-* MODE_RANDOM: Machine Modes. (line 273)
-* MODE_UACCUM: Machine Modes. (line 253)
-* MODE_UFRACT: Machine Modes. (line 245)
-* MODES_TIEABLE_P: Values in Registers.
- (line 129)
-* modifiers in constraints: Modifiers. (line 6)
-* MODIFY_EXPR: Expression trees. (line 6)
-* MODIFY_JNI_METHOD_CALL: Misc. (line 774)
-* MODIFY_TARGET_NAME: Driver. (line 385)
-* modM3 instruction pattern: Standard Names. (line 222)
-* modulo scheduling: RTL passes. (line 131)
-* MOVE_BY_PIECES_P: Costs. (line 110)
-* MOVE_MAX: Misc. (line 115)
-* MOVE_MAX_PIECES: Costs. (line 116)
-* MOVE_RATIO: Costs. (line 97)
-* movM instruction pattern: Standard Names. (line 11)
-* movmemM instruction pattern: Standard Names. (line 672)
-* movmisalignM instruction pattern: Standard Names. (line 126)
-* movMODEcc instruction pattern: Standard Names. (line 891)
-* movstr instruction pattern: Standard Names. (line 707)
-* movstrictM instruction pattern: Standard Names. (line 120)
-* msubMN4 instruction pattern: Standard Names. (line 387)
-* mulhisi3 instruction pattern: Standard Names. (line 340)
-* mulM3 instruction pattern: Standard Names. (line 222)
-* mulqihi3 instruction pattern: Standard Names. (line 344)
-* mulsidi3 instruction pattern: Standard Names. (line 344)
-* mult: Arithmetic. (line 92)
-* mult and attributes: Expressions. (line 64)
-* mult, canonicalization of: Insn Canonicalizations.
- (line 27)
-* MULT_EXPR: Expression trees. (line 6)
-* MULTILIB_DEFAULTS: Driver. (line 315)
-* MULTILIB_DIRNAMES: Target Fragment. (line 64)
-* MULTILIB_EXCEPTIONS: Target Fragment. (line 84)
-* MULTILIB_EXTRA_OPTS: Target Fragment. (line 96)
-* MULTILIB_MATCHES: Target Fragment. (line 77)
-* MULTILIB_OPTIONS: Target Fragment. (line 44)
-* multiple alternative constraints: Multi-Alternative. (line 6)
-* MULTIPLE_SYMBOL_SPACES: Misc. (line 530)
-* multiplication: Arithmetic. (line 92)
-* multiplication with signed saturation: Arithmetic. (line 92)
-* multiplication with unsigned saturation: Arithmetic. (line 92)
-* MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output.
- (line 64)
-* n in constraint: Simple Constraints. (line 65)
-* N_REG_CLASSES: Register Classes. (line 76)
-* name: Identifiers. (line 6)
-* named patterns and conditions: Patterns. (line 47)
-* names, pattern: Standard Names. (line 6)
-* namespace: Namespaces. (line 6)
-* namespace, class, scope: Scopes. (line 6)
-* NAMESPACE_DECL <1>: Declarations. (line 6)
-* NAMESPACE_DECL: Namespaces. (line 6)
-* NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103)
-* ne: Comparisons. (line 56)
-* ne and attributes: Expressions. (line 64)
-* NE_EXPR: Expression trees. (line 6)
-* nearbyintM2 instruction pattern: Standard Names. (line 564)
-* neg: Arithmetic. (line 81)
-* neg and attributes: Expressions. (line 64)
-* neg, canonicalization of: Insn Canonicalizations.
- (line 27)
-* NEGATE_EXPR: Expression trees. (line 6)
-* negation: Arithmetic. (line 81)
-* negation with signed saturation: Arithmetic. (line 81)
-* negation with unsigned saturation: Arithmetic. (line 81)
-* negM2 instruction pattern: Standard Names. (line 449)
-* nested functions, trampolines for: Trampolines. (line 6)
-* nested_ptr: GTY Options. (line 185)
-* next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10)
-* next_cc0_user: Jump Patterns. (line 64)
-* NEXT_INSN: Insns. (line 30)
-* NEXT_OBJC_RUNTIME: Library Calls. (line 94)
-* nil: RTL Objects. (line 73)
-* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39)
-* NO_DBX_FUNCTION_END: DBX Hooks. (line 33)
-* NO_DBX_GCC_MARKER: File Names and DBX. (line 28)
-* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23)
-* NO_DOLLAR_IN_LABEL: Misc. (line 494)
-* NO_DOT_IN_LABEL: Misc. (line 500)
-* NO_FUNCTION_CSE: Costs. (line 200)
-* NO_IMPLICIT_EXTERN_C: Misc. (line 376)
-* NO_PROFILE_COUNTERS: Profiling. (line 28)
-* NO_REGS: Register Classes. (line 17)
-* NON_LVALUE_EXPR: Expression trees. (line 6)
-* nondeterministic finite state automaton: Processor pipeline description.
- (line 296)
-* nonimmediate_operand: Machine-Independent Predicates.
- (line 101)
-* nonlocal goto handler: Edges. (line 171)
-* nonlocal_goto instruction pattern: Standard Names. (line 1255)
-* nonlocal_goto_receiver instruction pattern: Standard Names.
- (line 1272)
-* nonmemory_operand: Machine-Independent Predicates.
- (line 97)
-* nonoffsettable memory reference: Simple Constraints. (line 246)
-* nop instruction pattern: Standard Names. (line 1073)
-* NOP_EXPR: Expression trees. (line 6)
-* normal predicates: Predicates. (line 31)
-* not: Arithmetic. (line 149)
-* not and attributes: Expressions. (line 50)
-* not equal: Comparisons. (line 56)
-* not, canonicalization of: Insn Canonicalizations.
- (line 27)
-* note: Insns. (line 168)
-* note and /i: Flags. (line 59)
-* note and /v: Flags. (line 44)
-* NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41)
-* NOTE_INSN_BLOCK_BEG: Insns. (line 193)
-* NOTE_INSN_BLOCK_END: Insns. (line 193)
-* NOTE_INSN_DELETED: Insns. (line 183)
-* NOTE_INSN_DELETED_LABEL: Insns. (line 188)
-* NOTE_INSN_EH_REGION_BEG: Insns. (line 199)
-* NOTE_INSN_EH_REGION_END: Insns. (line 199)
-* NOTE_INSN_FUNCTION_BEG: Insns. (line 223)
-* NOTE_INSN_LOOP_BEG: Insns. (line 207)
-* NOTE_INSN_LOOP_CONT: Insns. (line 213)
-* NOTE_INSN_LOOP_END: Insns. (line 207)
-* NOTE_INSN_LOOP_VTOP: Insns. (line 217)
-* NOTE_LINE_NUMBER: Insns. (line 168)
-* NOTE_SOURCE_FILE: Insns. (line 168)
-* NOTICE_UPDATE_CC: Condition Code. (line 33)
-* NUM_MACHINE_MODES: Machine Modes. (line 286)
-* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30)
-* Number of iterations analysis: Number of iterations.
- (line 6)
-* o in constraint: Simple Constraints. (line 23)
-* OBJC_GEN_METHOD_LABEL: Label Output. (line 411)
-* OBJC_JBLEN: Misc. (line 924)
-* OBJECT_FORMAT_COFF: Macros for Initialization.
- (line 97)
-* OFFSET_TYPE: Types. (line 6)
-* offsettable address: Simple Constraints. (line 23)
-* OImode: Machine Modes. (line 51)
-* Omega a solver for linear programming problems: Omega. (line 6)
-* OMP_ATOMIC: Expression trees. (line 6)
-* OMP_CLAUSE: Expression trees. (line 6)
-* OMP_CONTINUE: Expression trees. (line 6)
-* OMP_CRITICAL: Expression trees. (line 6)
-* OMP_FOR: Expression trees. (line 6)
-* OMP_MASTER: Expression trees. (line 6)
-* OMP_ORDERED: Expression trees. (line 6)
-* OMP_PARALLEL: Expression trees. (line 6)
-* OMP_RETURN: Expression trees. (line 6)
-* OMP_SECTION: Expression trees. (line 6)
-* OMP_SECTIONS: Expression trees. (line 6)
-* OMP_SINGLE: Expression trees. (line 6)
-* one_cmplM2 instruction pattern: Standard Names. (line 651)
-* operand access: Accessors. (line 6)
-* Operand Access Routines: SSA Operands. (line 119)
-* operand constraints: Constraints. (line 6)
-* Operand Iterators: SSA Operands. (line 119)
-* operand predicates: Predicates. (line 6)
-* operand substitution: Output Template. (line 6)
-* operands <1>: Patterns. (line 53)
-* operands: SSA Operands. (line 6)
-* Operands: Operands. (line 6)
-* operator predicates: Predicates. (line 6)
-* optc-gen.awk: Options. (line 6)
-* Optimization infrastructure for GIMPLE: Tree SSA. (line 6)
-* OPTIMIZATION_OPTIONS: Run-time Target. (line 120)
-* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9)
-* option specification files: Options. (line 6)
-* OPTION_DEFAULT_SPECS: Driver. (line 88)
-* optional hardware or system features: Run-time Target. (line 59)
-* options, directory search: Including Patterns. (line 44)
-* order of register allocation: Allocation Order. (line 6)
-* ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23)
-* ORDERED_EXPR: Expression trees. (line 6)
-* Ordering of Patterns: Pattern Ordering. (line 6)
-* ORIGINAL_REGNO: Special Accessors. (line 40)
-* other register constraints: Simple Constraints. (line 163)
-* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 71)
-* OUTGOING_REGNO: Register Basics. (line 98)
-* output of assembler code: File Framework. (line 6)
-* output statements: Output Statement. (line 6)
-* output templates: Output Template. (line 6)
-* OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39)
-* output_asm_insn: Output Statement. (line 53)
-* OUTPUT_QUOTED_STRING: File Framework. (line 76)
-* OVERLOAD: Functions. (line 6)
-* OVERRIDE_ABI_FORMAT: Register Arguments. (line 140)
-* OVERRIDE_OPTIONS: Run-time Target. (line 104)
-* OVL_CURRENT: Functions. (line 6)
-* OVL_NEXT: Functions. (line 6)
-* p in constraint: Simple Constraints. (line 154)
-* PAD_VARARGS_DOWN: Register Arguments. (line 220)
-* parallel: Side Effects. (line 204)
-* param_is: GTY Options. (line 113)
-* parameters, c++ abi: C++ ABI. (line 6)
-* parameters, miscellaneous: Misc. (line 6)
-* parameters, precompiled headers: PCH Target. (line 6)
-* paramN_is: GTY Options. (line 131)
-* parity: Arithmetic. (line 228)
-* parityM2 instruction pattern: Standard Names. (line 645)
-* PARM_BOUNDARY: Storage Layout. (line 144)
-* PARM_DECL: Declarations. (line 6)
-* PARSE_LDD_OUTPUT: Macros for Initialization.
- (line 121)
-* passes and files of the compiler: Passes. (line 6)
-* passing arguments: Interface. (line 36)
-* PATH_SEPARATOR: Filesystem. (line 31)
-* PATTERN: Insns. (line 247)
-* 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 361)
-* pc and attributes: Insn Lengths. (line 20)
-* pc, RTL sharing: Sharing. (line 25)
-* PC_REGNUM: Register Basics. (line 112)
-* pc_rtx: Regs and Memory. (line 366)
-* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 314)
-* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64)
-* PDImode: Machine Modes. (line 40)
-* peephole optimization, RTL representation: Side Effects. (line 238)
-* 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)
-* phi_arg_d: GIMPLE_PHI. (line 28)
-* PHI_ARG_DEF: SSA. (line 71)
-* PHI_ARG_EDGE: SSA. (line 68)
-* PHI_ARG_ELT: SSA. (line 63)
-* PHI_NUM_ARGS: SSA. (line 59)
-* PHI_RESULT: SSA. (line 56)
-* PIC: PIC. (line 6)
-* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26)
-* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16)
-* pipeline hazard recognizer: Processor pipeline description.
- (line 6)
-* plus: Arithmetic. (line 14)
-* plus and attributes: Expressions. (line 64)
-* plus, canonicalization of: Insn Canonicalizations.
- (line 27)
-* PLUS_EXPR: Expression trees. (line 6)
-* Pmode: Misc. (line 344)
-* pmode_register_operand: Machine-Independent Predicates.
- (line 35)
-* pointer: Types. (line 6)
-* POINTER_PLUS_EXPR: Expression trees. (line 6)
-* POINTER_SIZE: Storage Layout. (line 83)
-* POINTER_TYPE: Types. (line 6)
-* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89)
-* pop_operand: Machine-Independent Predicates.
- (line 88)
-* popcount: Arithmetic. (line 224)
-* popcountM2 instruction pattern: Standard Names. (line 639)
-* portability: Portability. (line 6)
-* position independent code: PIC. (line 6)
-* post_dec: Incdec. (line 25)
-* post_inc: Incdec. (line 30)
-* post_modify: Incdec. (line 33)
-* POSTDECREMENT_EXPR: Expression trees. (line 6)
-* POSTINCREMENT_EXPR: Expression trees. (line 6)
-* POWI_MAX_MULTS: Misc. (line 822)
-* powM3 instruction pattern: Standard Names. (line 513)
-* pragma: Misc. (line 381)
-* pre_dec: Incdec. (line 8)
-* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110)
-* pre_inc: Incdec. (line 22)
-* pre_modify: Incdec. (line 51)
-* PREDECREMENT_EXPR: Expression trees. (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 42)
-* PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 231)
-* PREFERRED_RELOAD_CLASS: Register Classes. (line 196)
-* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 158)
-* prefetch: Side Effects. (line 312)
-* prefetch instruction pattern: Standard Names. (line 1392)
-* PREINCREMENT_EXPR: Expression trees. (line 6)
-* presence_set: Processor pipeline description.
- (line 215)
-* preserving SSA form: SSA. (line 76)
-* preserving virtual SSA form: SSA. (line 186)
-* prev_active_insn: define_peephole. (line 60)
-* prev_cc0_setter: Jump Patterns. (line 64)
-* PREV_INSN: Insns. (line 26)
-* PRINT_OPERAND: Instruction Output. (line 68)
-* PRINT_OPERAND_ADDRESS: Instruction Output. (line 96)
-* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89)
-* processor functional units: Processor pipeline description.
- (line 6)
-* processor pipeline description: Processor pipeline description.
- (line 6)
-* product: Arithmetic. (line 92)
-* profile feedback: Profile information.
- (line 14)
-* profile representation: Profile information.
- (line 6)
-* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35)
-* PROFILE_HOOK: Profiling. (line 23)
-* profiling, code generation: Profiling. (line 6)
-* program counter: Regs and Memory. (line 362)
-* prologue: Function Entry. (line 6)
-* prologue instruction pattern: Standard Names. (line 1338)
-* PROMOTE_FUNCTION_MODE: Storage Layout. (line 123)
-* PROMOTE_MODE: Storage Layout. (line 100)
-* pseudo registers: Regs and Memory. (line 9)
-* PSImode: Machine Modes. (line 32)
-* PTRDIFF_TYPE: Type Layout. (line 184)
-* PTRMEM_CST: Expression trees. (line 6)
-* PTRMEM_CST_CLASS: Expression trees. (line 6)
-* PTRMEM_CST_MEMBER: Expression trees. (line 6)
-* purge_dead_edges <1>: Maintaining the CFG.
- (line 93)
-* purge_dead_edges: Edges. (line 104)
-* push address instruction: Simple Constraints. (line 154)
-* PUSH_ARGS: Stack Arguments. (line 18)
-* PUSH_ARGS_REVERSED: Stack Arguments. (line 26)
-* push_operand: Machine-Independent Predicates.
- (line 81)
-* push_reload: Addressing Modes. (line 169)
-* PUSH_ROUNDING: Stack Arguments. (line 32)
-* pushM1 instruction pattern: Standard Names. (line 209)
-* PUT_CODE: RTL Objects. (line 47)
-* PUT_MODE: Machine Modes. (line 283)
-* PUT_REG_NOTE_KIND: Insns. (line 309)
-* PUT_SDB_: SDB and DWARF. (line 63)
-* QCmode: Machine Modes. (line 197)
-* QFmode: Machine Modes. (line 54)
-* QImode: Machine Modes. (line 25)
-* QImode, in insn: Insns. (line 231)
-* QQmode: Machine Modes. (line 103)
-* qualified type: Types. (line 6)
-* querying function unit reservations: Processor pipeline description.
- (line 90)
-* question mark: Multi-Alternative. (line 41)
-* quotient: Arithmetic. (line 111)
-* r in constraint: Simple Constraints. (line 56)
-* RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 204)
-* RDIV_EXPR: Expression trees. (line 6)
-* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63)
-* real operands: SSA Operands. (line 6)
-* REAL_ARITHMETIC: Floating Point. (line 66)
-* REAL_CST: Expression trees. (line 6)
-* REAL_LIBGCC_SPEC: Driver. (line 187)
-* REAL_NM_FILE_NAME: Macros for Initialization.
- (line 106)
-* REAL_TYPE: Types. (line 6)
-* REAL_VALUE_ABS: Floating Point. (line 82)
-* REAL_VALUE_ATOF: Floating Point. (line 50)
-* REAL_VALUE_FIX: Floating Point. (line 41)
-* REAL_VALUE_FROM_INT: Floating Point. (line 99)
-* REAL_VALUE_ISINF: Floating Point. (line 59)
-* REAL_VALUE_ISNAN: Floating Point. (line 62)
-* REAL_VALUE_NEGATE: Floating Point. (line 79)
-* REAL_VALUE_NEGATIVE: Floating Point. (line 56)
-* REAL_VALUE_TO_INT: Floating Point. (line 93)
-* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 144)
-* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 142)
-* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 143)
-* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 140)
-* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 141)
-* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 139)
-* REAL_VALUE_TRUNCATE: Floating Point. (line 86)
-* REAL_VALUE_TYPE: Floating Point. (line 26)
-* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45)
-* REAL_VALUES_EQUAL: Floating Point. (line 32)
-* REAL_VALUES_LESS: Floating Point. (line 38)
-* REALPART_EXPR: Expression trees. (line 6)
-* recog_data.operand: Instruction Output. (line 39)
-* recognizing insns: RTL Template. (line 6)
-* RECORD_TYPE <1>: Classes. (line 6)
-* RECORD_TYPE: Types. (line 6)
-* redirect_edge_and_branch: Profile information.
- (line 71)
-* redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
- (line 103)
-* reduc_smax_M instruction pattern: Standard Names. (line 240)
-* reduc_smin_M instruction pattern: Standard Names. (line 240)
-* reduc_splus_M instruction pattern: Standard Names. (line 252)
-* reduc_umax_M instruction pattern: Standard Names. (line 246)
-* reduc_umin_M instruction pattern: Standard Names. (line 246)
-* reduc_uplus_M instruction pattern: Standard Names. (line 258)
-* reference: Types. (line 6)
-* REFERENCE_TYPE: Types. (line 6)
-* reg: Regs and Memory. (line 9)
-* reg and /f: Flags. (line 112)
-* reg and /i: Flags. (line 107)
-* reg and /v: Flags. (line 116)
-* reg, RTL sharing: Sharing. (line 17)
-* REG_ALLOC_ORDER: Allocation Order. (line 9)
-* REG_BR_PRED: Insns. (line 491)
-* REG_BR_PROB: Insns. (line 485)
-* 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 456)
-* REG_CC_USER: Insns. (line 456)
-* REG_CLASS_CONTENTS: Register Classes. (line 86)
-* reg_class_contents: Register Basics. (line 59)
-* REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35)
-* REG_CLASS_FROM_LETTER: Old Constraints. (line 27)
-* REG_CLASS_NAMES: Register Classes. (line 81)
-* REG_CROSSING_JUMP: Insns. (line 368)
-* REG_DEAD: Insns. (line 320)
-* REG_DEAD, REG_UNUSED: Liveness information.
- (line 32)
-* REG_DEP_ANTI: Insns. (line 478)
-* REG_DEP_OUTPUT: Insns. (line 474)
-* REG_DEP_TRUE: Insns. (line 471)
-* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110)
-* REG_EQUAL: Insns. (line 384)
-* REG_EQUIV: Insns. (line 384)
-* REG_EXPR: Special Accessors. (line 46)
-* REG_FRAME_RELATED_EXPR: Insns. (line 497)
-* REG_FUNCTION_VALUE_P: Flags. (line 107)
-* REG_INC: Insns. (line 336)
-* reg_label and /v: Flags. (line 65)
-* REG_LABEL_OPERAND: Insns. (line 350)
-* REG_LABEL_TARGET: Insns. (line 359)
-* reg_names <1>: Instruction Output. (line 80)
-* reg_names: Register Basics. (line 59)
-* REG_NONNEG: Insns. (line 342)
-* REG_NOTE_KIND: Insns. (line 309)
-* REG_NOTES: Insns. (line 283)
-* REG_OFFSET: Special Accessors. (line 50)
-* REG_OK_STRICT: Addressing Modes. (line 67)
-* REG_PARM_STACK_SPACE: Stack Arguments. (line 56)
-* REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments.
- (line 52)
-* REG_POINTER: Flags. (line 112)
-* REG_SETJMP: Insns. (line 378)
-* REG_UNUSED: Insns. (line 329)
-* REG_USERVAR_P: Flags. (line 116)
-* regclass_for_constraint: C Constraint Interface.
- (line 60)
-* 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)
-* REGISTER_MOVE_COST: Costs. (line 10)
-* REGISTER_NAMES: Instruction Output. (line 9)
-* register_operand: Machine-Independent Predicates.
- (line 30)
-* REGISTER_PREFIX: Instruction Output. (line 124)
-* REGISTER_TARGET_PRAGMAS: Misc. (line 382)
-* registers arguments: Register Arguments. (line 6)
-* registers in constraints: Simple Constraints. (line 56)
-* REGMODE_NATURAL_SIZE: Values in Registers.
- (line 50)
-* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 170)
-* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 146)
-* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 157)
-* REGNO_OK_FOR_BASE_P: Register Classes. (line 140)
-* REGNO_OK_FOR_INDEX_P: Register Classes. (line 181)
-* REGNO_REG_CLASS: Register Classes. (line 101)
-* regs_ever_live: Function Entry. (line 21)
-* regular expressions: Processor pipeline description.
- (line 6)
-* relative costs: Costs. (line 6)
-* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325)
-* reload_completed: Standard Names. (line 1040)
-* reload_in instruction pattern: Standard Names. (line 99)
-* reload_in_progress: Standard Names. (line 57)
-* reload_out instruction pattern: Standard Names. (line 99)
-* reloading: RTL passes. (line 182)
-* remainder: Arithmetic. (line 131)
-* remainderM3 instruction pattern: Standard Names. (line 472)
-* reorder: GTY Options. (line 209)
-* representation of RTL: RTL. (line 6)
-* reservation delays: Processor pipeline description.
- (line 6)
-* rest_of_decl_compilation: Parsing pass. (line 52)
-* rest_of_type_compilation: Parsing pass. (line 52)
-* restore_stack_block instruction pattern: Standard Names. (line 1174)
-* restore_stack_function instruction pattern: Standard Names.
- (line 1174)
-* restore_stack_nonlocal instruction pattern: Standard Names.
- (line 1174)
-* RESULT_DECL: Declarations. (line 6)
-* return: Side Effects. (line 72)
-* return instruction pattern: Standard Names. (line 1027)
-* return values in registers: Scalar Return. (line 6)
-* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135)
-* RETURN_ADDR_OFFSET: Exception Handling. (line 60)
-* RETURN_ADDR_RTX: Frame Layout. (line 124)
-* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51)
-* RETURN_EXPR: Function Bodies. (line 6)
-* RETURN_POPS_ARGS: Stack Arguments. (line 90)
-* RETURN_STMT: Function Bodies. (line 6)
-* return_val: Flags. (line 294)
-* return_val, in call_insn: Flags. (line 24)
-* return_val, in mem: Flags. (line 85)
-* return_val, in reg: Flags. (line 107)
-* return_val, in symbol_ref: Flags. (line 220)
-* returning aggregate values: Aggregate Return. (line 6)
-* returning structures and unions: Interface. (line 10)
-* reverse probability: Profile information.
- (line 66)
-* REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129)
-* REVERSE_CONDITION: Condition Code. (line 116)
-* REVERSIBLE_CC_MODE: Condition Code. (line 102)
-* right rotate: Arithmetic. (line 190)
-* right shift: Arithmetic. (line 185)
-* rintM2 instruction pattern: Standard Names. (line 572)
-* RISC: Processor pipeline description.
- (line 6)
-* roots, marking: GGC Roots. (line 6)
-* rotate: Arithmetic. (line 190)
-* rotatert: Arithmetic. (line 190)
-* rotlM3 instruction pattern: Standard Names. (line 441)
-* rotrM3 instruction pattern: Standard Names. (line 441)
-* ROUND_DIV_EXPR: Expression trees. (line 6)
-* ROUND_MOD_EXPR: Expression trees. (line 6)
-* ROUND_TOWARDS_ZERO: Storage Layout. (line 460)
-* ROUND_TYPE_ALIGN: Storage Layout. (line 411)
-* roundM2 instruction pattern: Standard Names. (line 548)
-* RSHIFT_EXPR: Expression trees. (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 43)
-* 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 36)
-* RTL expression: RTL Objects. (line 6)
-* RTL expressions for arithmetic: Arithmetic. (line 6)
-* RTL format: RTL Classes. (line 71)
-* RTL format characters: RTL Classes. (line 76)
-* 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 36)
-* RTL subtraction with signed saturation: Arithmetic. (line 36)
-* RTL subtraction with unsigned saturation: Arithmetic. (line 36)
-* 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 125)
-* run-time conventions: Interface. (line 6)
-* run-time target specification: Run-time Target. (line 6)
-* s in constraint: Simple Constraints. (line 92)
-* same_type_p: Types. (line 148)
-* SAmode: Machine Modes. (line 148)
-* sat_fract: Conversions. (line 90)
-* satfractMN2 instruction pattern: Standard Names. (line 843)
-* satfractunsMN2 instruction pattern: Standard Names. (line 856)
-* satisfies_constraint_: C Constraint Interface.
- (line 47)
-* SAVE_EXPR: Expression trees. (line 6)
-* save_stack_block instruction pattern: Standard Names. (line 1174)
-* save_stack_function instruction pattern: Standard Names. (line 1174)
-* save_stack_nonlocal instruction pattern: Standard Names. (line 1174)
-* SBSS_SECTION_ASM_OP: Sections. (line 77)
-* Scalar evolutions: Scalar evolutions. (line 6)
-* scalars, returned as values: Scalar Return. (line 6)
-* SCHED_GROUP_P: Flags. (line 166)
-* SCmode: Machine Modes. (line 197)
-* sCOND instruction pattern: Standard Names. (line 911)
-* scratch: Regs and Memory. (line 298)
-* scratch operands: Regs and Memory. (line 298)
-* scratch, RTL sharing: Sharing. (line 35)
-* scratch_operand: Machine-Independent Predicates.
- (line 50)
-* SDATA_SECTION_ASM_OP: Sections. (line 58)
-* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 81)
-* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 76)
-* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9)
-* SDB_DELIM: SDB and DWARF. (line 69)
-* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 86)
-* SDmode: Machine Modes. (line 85)
-* sdot_prodM instruction pattern: Standard Names. (line 264)
-* search options: Including Patterns. (line 44)
-* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 335)
-* SECONDARY_MEMORY_NEEDED: Register Classes. (line 391)
-* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 410)
-* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 401)
-* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 336)
-* SECONDARY_RELOAD_CLASS: Register Classes. (line 334)
-* SELECT_CC_MODE: Condition Code. (line 68)
-* sequence: Side Effects. (line 254)
-* Sequence iterators: Sequence iterators. (line 6)
-* set: Side Effects. (line 15)
-* set and /f: Flags. (line 125)
-* SET_ASM_OP: Label Output. (line 378)
-* set_attr: Tagging Insns. (line 31)
-* set_attr_alternative: Tagging Insns. (line 49)
-* set_bb_seq: GIMPLE sequences. (line 76)
-* SET_BY_PIECES_P: Costs. (line 145)
-* SET_DEST: Side Effects. (line 69)
-* SET_IS_RETURN_P: Flags. (line 175)
-* SET_LABEL_KIND: Insns. (line 140)
-* set_optab_libfunc: Library Calls. (line 15)
-* SET_RATIO: Costs. (line 136)
-* SET_SRC: Side Effects. (line 69)
-* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6)
-* setmemM instruction pattern: Standard Names. (line 715)
-* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102)
-* SF_SIZE: Type Layout. (line 129)
-* SFmode: Machine Modes. (line 66)
-* sharing of RTL components: Sharing. (line 6)
-* shift: Arithmetic. (line 168)
-* SHIFT_COUNT_TRUNCATED: Misc. (line 127)
-* SHLIB_SUFFIX: Macros for Initialization.
- (line 129)
-* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83)
-* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63)
-* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96)
-* SHORT_TYPE_SIZE: Type Layout. (line 16)
-* sibcall_epilogue instruction pattern: Standard Names. (line 1364)
-* sibling call: Edges. (line 122)
-* SIBLING_CALL_P: Flags. (line 179)
-* sign_extend: Conversions. (line 23)
-* sign_extract: Bit-Fields. (line 8)
-* sign_extract, canonicalization of: Insn Canonicalizations.
- (line 96)
-* signed division: Arithmetic. (line 111)
-* signed division with signed saturation: Arithmetic. (line 111)
-* signed maximum: Arithmetic. (line 136)
-* signed minimum: Arithmetic. (line 136)
-* SImode: Machine Modes. (line 37)
-* simple constraints: Simple Constraints. (line 6)
-* sincos math function, implicit usage: Library Calls. (line 84)
-* sinM2 instruction pattern: Standard Names. (line 489)
-* SIZE_ASM_OP: Label Output. (line 23)
-* SIZE_TYPE: Type Layout. (line 168)
-* skip: GTY Options. (line 76)
-* SLOW_BYTE_ACCESS: Costs. (line 66)
-* SLOW_UNALIGNED_ACCESS: Costs. (line 81)
-* SMALL_REGISTER_CLASSES: Register Classes. (line 433)
-* smax: Arithmetic. (line 136)
-* smin: Arithmetic. (line 136)
-* sms, swing, software pipelining: RTL passes. (line 131)
-* smulM3_highpart instruction pattern: Standard Names. (line 356)
-* soft float library: Soft float library routines.
- (line 6)
-* special: GTY Options. (line 229)
-* special predicates: Predicates. (line 31)
-* SPECS: Target Fragment. (line 108)
-* speed of instructions: Costs. (line 6)
-* split_block: Maintaining the CFG.
- (line 110)
-* splitting instructions: Insn Splitting. (line 6)
-* SQmode: Machine Modes. (line 111)
-* sqrt: Arithmetic. (line 198)
-* sqrtM2 instruction pattern: Standard Names. (line 455)
-* square root: Arithmetic. (line 198)
-* ss_ashift: Arithmetic. (line 168)
-* ss_div: Arithmetic. (line 111)
-* ss_minus: Arithmetic. (line 36)
-* ss_mult: Arithmetic. (line 92)
-* ss_neg: Arithmetic. (line 81)
-* ss_plus: Arithmetic. (line 14)
-* ss_truncate: Conversions. (line 43)
-* SSA: SSA. (line 6)
-* SSA_NAME_DEF_STMT: SSA. (line 221)
-* SSA_NAME_VERSION: SSA. (line 226)
-* ssaddM3 instruction pattern: Standard Names. (line 222)
-* ssashlM3 instruction pattern: Standard Names. (line 431)
-* ssdivM3 instruction pattern: Standard Names. (line 222)
-* ssmaddMN4 instruction pattern: Standard Names. (line 379)
-* ssmsubMN4 instruction pattern: Standard Names. (line 403)
-* ssmulM3 instruction pattern: Standard Names. (line 222)
-* ssnegM2 instruction pattern: Standard Names. (line 449)
-* sssubM3 instruction pattern: Standard Names. (line 222)
-* ssum_widenM3 instruction pattern: Standard Names. (line 274)
-* 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 48)
-* STACK_BOUNDARY: Storage Layout. (line 150)
-* STACK_CHECK_BUILTIN: Stack Checking. (line 32)
-* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 77)
-* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 68)
-* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 84)
-* STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 46)
-* STACK_CHECK_PROBE_LOAD: Stack Checking. (line 53)
-* STACK_CHECK_PROTECT: Stack Checking. (line 59)
-* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39)
-* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75)
-* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory.
- (line 83)
-* STACK_GROWS_DOWNWARD: Frame Layout. (line 9)
-* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 81)
-* STACK_POINTER_OFFSET: Frame Layout. (line 58)
-* STACK_POINTER_OFFSET and virtual registers: Regs and Memory.
- (line 93)
-* STACK_POINTER_REGNUM: Frame Registers. (line 9)
-* STACK_POINTER_REGNUM and virtual registers: Regs and Memory.
- (line 83)
-* stack_pointer_rtx: Frame Registers. (line 85)
-* stack_protect_set instruction pattern: Standard Names. (line 1534)
-* stack_protect_test instruction pattern: Standard Names. (line 1544)
-* STACK_PUSH_CODE: Frame Layout. (line 17)
-* STACK_REGS: Stack Registers. (line 20)
-* STACK_SAVEAREA_MODE: Storage Layout. (line 427)
-* STACK_SIZE_MODE: Storage Layout. (line 439)
-* STACK_SLOT_ALIGNMENT: Storage Layout. (line 265)
-* standard pattern names: Standard Names. (line 6)
-* STANDARD_INCLUDE_COMPONENT: Driver. (line 425)
-* STANDARD_INCLUDE_DIR: Driver. (line 417)
-* STANDARD_STARTFILE_PREFIX: Driver. (line 337)
-* STANDARD_STARTFILE_PREFIX_1: Driver. (line 344)
-* STANDARD_STARTFILE_PREFIX_2: Driver. (line 351)
-* STARTFILE_SPEC: Driver. (line 210)
-* STARTING_FRAME_OFFSET: Frame Layout. (line 39)
-* 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 Bodies. (line 6)
-* Static profile estimation: Profile information.
- (line 24)
-* static single assignment: SSA. (line 6)
-* STATIC_CHAIN: Frame Registers. (line 77)
-* STATIC_CHAIN_INCOMING: Frame Registers. (line 78)
-* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64)
-* STATIC_CHAIN_REGNUM: Frame Registers. (line 63)
-* stdarg.h and register arguments: Register Arguments. (line 47)
-* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 365)
-* STMT_EXPR: Expression trees. (line 6)
-* STMT_IS_FULL_EXPR_P: Function Bodies. (line 22)
-* storage layout: Storage Layout. (line 6)
-* STORE_BY_PIECES_P: Costs. (line 152)
-* STORE_FLAG_VALUE: Misc. (line 216)
-* store_multiple instruction pattern: Standard Names. (line 160)
-* strcpy: Storage Layout. (line 235)
-* STRICT_ALIGNMENT: Storage Layout. (line 309)
-* strict_low_part: RTL Declarations. (line 9)
-* strict_memory_address_p: Addressing Modes. (line 179)
-* STRING_CST: Expression trees. (line 6)
-* STRING_POOL_ADDRESS_P: Flags. (line 183)
-* strlenM instruction pattern: Standard Names. (line 778)
-* structure value address: Aggregate Return. (line 6)
-* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 301)
-* structures, returning: Interface. (line 10)
-* subM3 instruction pattern: Standard Names. (line 222)
-* SUBOBJECT: Function Bodies. (line 6)
-* SUBOBJECT_CLEANUP: Function Bodies. (line 6)
-* subreg: Regs and Memory. (line 97)
-* subreg and /s: Flags. (line 205)
-* subreg and /u: Flags. (line 198)
-* subreg and /u and /v: Flags. (line 188)
-* subreg, in strict_low_part: RTL Declarations. (line 9)
-* SUBREG_BYTE: Regs and Memory. (line 289)
-* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 188)
-* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 198)
-* SUBREG_PROMOTED_VAR_P: Flags. (line 205)
-* SUBREG_REG: Regs and Memory. (line 289)
-* SUCCESS_EXIT_CODE: Host Misc. (line 12)
-* SUPPORTS_INIT_PRIORITY: Macros for Initialization.
- (line 58)
-* SUPPORTS_ONE_ONLY: Label Output. (line 227)
-* SUPPORTS_WEAK: Label Output. (line 208)
-* SWITCH_BODY: Function Bodies. (line 6)
-* SWITCH_COND: Function Bodies. (line 6)
-* SWITCH_CURTAILS_COMPILATION: Driver. (line 33)
-* SWITCH_STMT: Function Bodies. (line 6)
-* SWITCH_TAKES_ARG: Driver. (line 9)
-* SWITCHES_NEED_SPACES: Driver. (line 47)
-* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 106)
-* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 88)
-* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 81)
-* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 102)
-* SYMBOL_FLAG_LOCAL: Special Accessors. (line 84)
-* SYMBOL_FLAG_SMALL: Special Accessors. (line 93)
-* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 97)
-* symbol_ref: Constants. (line 76)
-* symbol_ref and /f: Flags. (line 183)
-* symbol_ref and /i: Flags. (line 220)
-* symbol_ref and /u: Flags. (line 10)
-* symbol_ref and /v: Flags. (line 224)
-* symbol_ref, RTL sharing: Sharing. (line 20)
-* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 106)
-* SYMBOL_REF_BLOCK: Special Accessors. (line 119)
-* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 124)
-* SYMBOL_REF_CONSTANT: Special Accessors. (line 67)
-* SYMBOL_REF_DATA: Special Accessors. (line 71)
-* SYMBOL_REF_DECL: Special Accessors. (line 55)
-* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 88)
-* SYMBOL_REF_FLAG: Flags. (line 224)
-* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 259)
-* SYMBOL_REF_FLAGS: Special Accessors. (line 75)
-* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 81)
-* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 102)
-* SYMBOL_REF_LOCAL_P: Special Accessors. (line 84)
-* SYMBOL_REF_SMALL_P: Special Accessors. (line 93)
-* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 97)
-* SYMBOL_REF_USED: Flags. (line 215)
-* SYMBOL_REF_WEAK: Flags. (line 220)
-* symbolic label: Sharing. (line 20)
-* sync_addMODE instruction pattern: Standard Names. (line 1450)
-* sync_andMODE instruction pattern: Standard Names. (line 1450)
-* sync_compare_and_swap_ccMODE instruction pattern: Standard Names.
- (line 1437)
-* sync_compare_and_swapMODE instruction pattern: Standard Names.
- (line 1419)
-* sync_iorMODE instruction pattern: Standard Names. (line 1450)
-* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1515)
-* sync_lock_test_and_setMODE instruction pattern: Standard Names.
- (line 1489)
-* sync_nandMODE instruction pattern: Standard Names. (line 1450)
-* sync_new_addMODE instruction pattern: Standard Names. (line 1482)
-* sync_new_andMODE instruction pattern: Standard Names. (line 1482)
-* sync_new_iorMODE instruction pattern: Standard Names. (line 1482)
-* sync_new_nandMODE instruction pattern: Standard Names. (line 1482)
-* sync_new_subMODE instruction pattern: Standard Names. (line 1482)
-* sync_new_xorMODE instruction pattern: Standard Names. (line 1482)
-* sync_old_addMODE instruction pattern: Standard Names. (line 1465)
-* sync_old_andMODE instruction pattern: Standard Names. (line 1465)
-* sync_old_iorMODE instruction pattern: Standard Names. (line 1465)
-* sync_old_nandMODE instruction pattern: Standard Names. (line 1465)
-* sync_old_subMODE instruction pattern: Standard Names. (line 1465)
-* sync_old_xorMODE instruction pattern: Standard Names. (line 1465)
-* sync_subMODE instruction pattern: Standard Names. (line 1450)
-* sync_xorMODE instruction pattern: Standard Names. (line 1450)
-* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239)
-* SYSROOT_SUFFIX_SPEC: Driver. (line 234)
-* SYSTEM_INCLUDE_DIR: Driver. (line 408)
-* t-TARGET: Target Fragment. (line 6)
-* table jump: Basic Blocks. (line 57)
-* tablejump instruction pattern: Standard Names. (line 1102)
-* tag: GTY Options. (line 81)
-* tagging insns: Tagging Insns. (line 6)
-* tail calls: Tail Calls. (line 6)
-* TAmode: Machine Modes. (line 156)
-* 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)
-* TARGET_ADDRESS_COST: Costs. (line 236)
-* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 386)
-* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 712)
-* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 945)
-* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83)
-* TARGET_ARM_EABI_UNWINDER: Exception Region Output.
- (line 113)
-* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10)
-* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8)
-* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9)
-* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11)
-* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 239)
-* TARGET_ASM_BYTE_OP: Data Output. (line 7)
-* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237)
-* TARGET_ASM_CLOSE_PAREN: Data Output. (line 130)
-* TARGET_ASM_CONSTRUCTOR: Macros for Initialization.
- (line 69)
-* TARGET_ASM_DESTRUCTOR: Macros for Initialization.
- (line 83)
-* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74)
-* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63)
-* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 274)
-* TARGET_ASM_FILE_END: File Framework. (line 37)
-* TARGET_ASM_FILE_START: File Framework. (line 9)
-* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17)
-* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31)
-* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61)
-* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55)
-* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68)
-* TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 70)
-* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11)
-* TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 70)
-* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 206)
-* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 174)
-* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165)
-* TARGET_ASM_INIT_SECTIONS: Sections. (line 151)
-* TARGET_ASM_INTEGER: Data Output. (line 27)
-* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 309)
-* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 280)
-* TARGET_ASM_NAMED_SECTION: File Framework. (line 89)
-* TARGET_ASM_OPEN_PAREN: Data Output. (line 129)
-* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44)
-* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 58)
-* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195)
-* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 122)
-* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 166)
-* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 214)
-* TARGET_ASM_SELECT_SECTION: Sections. (line 172)
-* TARGET_ASM_TTYPE: Exception Region Output.
- (line 107)
-* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14)
-* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12)
-* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13)
-* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15)
-* TARGET_ASM_UNIQUE_SECTION: Sections. (line 193)
-* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11)
-* TARGET_BINDS_LOCAL_P: Sections. (line 284)
-* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 808)
-* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 800)
-* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 263)
-* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 240)
-* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109)
-* TARGET_C99_FUNCTIONS: Library Calls. (line 77)
-* TARGET_CALLEE_COPIES: Register Arguments. (line 115)
-* TARGET_CAN_INLINE_P: Target Attributes. (line 126)
-* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 221)
-* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 787)
-* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 272)
-* TARGET_COMMUTATIVE_P: Misc. (line 705)
-* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19)
-* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9)
-* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87)
-* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38)
-* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62)
-* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25)
-* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54)
-* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18)
-* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12)
-* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7)
-* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30)
-* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43)
-* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69)
-* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74)
-* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80)
-* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 513)
-* TARGET_DECLSPEC: Target Attributes. (line 64)
-* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 482)
-* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 160)
-* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 393)
-* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 212)
-* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47)
-* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18)
-* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172)
-* TARGET_DWARF_REGISTER_SPAN: Exception Region Output.
- (line 90)
-* TARGET_EDOM: Library Calls. (line 59)
-* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68)
-* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19)
-* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24)
-* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45)
-* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36)
-* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63)
-* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49)
-* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57)
-* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41)
-* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31)
-* TARGET_ENCODE_SECTION_INFO: Sections. (line 235)
-* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes.
- (line 91)
-* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100)
-* TARGET_ENUM_VA_LIST: Scalar Return. (line 84)
-* TARGET_EXECUTABLE_SUFFIX: Misc. (line 761)
-* TARGET_EXPAND_BUILTIN: Misc. (line 657)
-* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92)
-* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 519)
-* TARGET_EXPR: Expression trees. (line 6)
-* TARGET_EXTRA_INCLUDES: Misc. (line 833)
-* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21)
-* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 840)
-* TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 142)
-* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 516)
-* target_flags: Run-time Target. (line 52)
-* TARGET_FLT_EVAL_METHOD: Type Layout. (line 141)
-* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 267)
-* TARGET_FOLD_BUILTIN: Misc. (line 677)
-* TARGET_FORMAT_TYPES: Misc. (line 860)
-* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 86)
-* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8)
-* TARGET_FUNCTION_VALUE: Scalar Return. (line 11)
-* TARGET_GET_DRAP_RTX: Misc. (line 940)
-* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 278)
-* TARGET_HANDLE_C_OPTION: Run-time Target. (line 78)
-* TARGET_HANDLE_OPTION: Run-time Target. (line 61)
-* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers.
- (line 144)
-* TARGET_HAS_SINCOS: Library Calls. (line 85)
-* TARGET_HAVE_CTORS_DTORS: Macros for Initialization.
- (line 64)
-* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 99)
-* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 103)
-* TARGET_HELP: Run-time Target. (line 140)
-* TARGET_IN_SMALL_DATA_P: Sections. (line 276)
-* TARGET_INIT_BUILTINS: Misc. (line 639)
-* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output.
- (line 99)
-* TARGET_INIT_LIBFUNCS: Library Calls. (line 16)
-* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 73)
-* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 527)
-* TARGET_INVALID_BINARY_OP: Misc. (line 913)
-* TARGET_INVALID_CONVERSION: Misc. (line 900)
-* TARGET_INVALID_UNARY_OP: Misc. (line 906)
-* TARGET_IRA_COVER_CLASSES: Register Classes. (line 496)
-* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35)
-* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 448)
-* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 123)
-* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 454)
-* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 624)
-* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 225)
-* TARGET_MANGLE_TYPE: Storage Layout. (line 531)
-* TARGET_MD_ASM_CLOBBERS: Misc. (line 540)
-* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 100)
-* TARGET_MEM_REF: Expression trees. (line 6)
-* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39)
-* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31)
-* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106)
-* TARGET_MODE_REP_EXTENDED: Misc. (line 191)
-* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 486)
-* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62)
-* TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments.
- (line 52)
-* TARGET_N_FORMAT_TYPES: Misc. (line 865)
-* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 392)
-* TARGET_OBJECT_SUFFIX: Misc. (line 756)
-* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46)
-* TARGET_OPTF: Misc. (line 847)
-* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 120)
-* TARGET_OPTION_PRINT: Target Attributes. (line 115)
-* TARGET_OPTION_RESTORE: Target Attributes. (line 110)
-* TARGET_OPTION_SAVE: Target Attributes. (line 104)
-* TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53)
-* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42)
-* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 869)
-* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 875)
-* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 879)
-* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103)
-* TARGET_POSIX_IO: Misc. (line 564)
-* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152)
-* TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 131)
-* TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 136)
-* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11)
-* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 235)
-* TARGET_RELAXED_ORDERING: Misc. (line 884)
-* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 667)
-* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16)
-* TARGET_RETURN_IN_MSB: Scalar Return. (line 100)
-* TARGET_RTX_COSTS: Costs. (line 210)
-* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 290)
-* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37)
-* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52)
-* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 261)
-* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89)
-* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 205)
-* TARGET_SCHED_DFA_POST_CYCLE_ADVANCE: Scheduling. (line 160)
-* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144)
-* TARGET_SCHED_DFA_PRE_CYCLE_ADVANCE: Scheduling. (line 153)
-* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132)
-* TARGET_SCHED_FINISH: Scheduling. (line 109)
-* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
- (line 168)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
- (line 196)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling.
- (line 321)
-* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 265)
-* TARGET_SCHED_GEN_CHECK: Scheduling. (line 309)
-* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 241)
-* TARGET_SCHED_INIT: Scheduling. (line 99)
-* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149)
-* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141)
-* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118)
-* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 251)
-* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 219)
-* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12)
-* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 302)
-* TARGET_SCHED_REORDER: Scheduling. (line 60)
-* TARGET_SCHED_REORDER2: Scheduling. (line 77)
-* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 257)
-* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 332)
-* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 343)
-* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 291)
-* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24)
-* TARGET_SECONDARY_RELOAD: Register Classes. (line 257)
-* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 109)
-* TARGET_SET_CURRENT_FUNCTION: Misc. (line 739)
-* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26)
-* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101)
-* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154)
-* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 251)
-* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection.
- (line 17)
-* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection.
- (line 7)
-* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137)
-* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44)
-* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 731)
-* TARGET_UNWIND_EMIT: Dispatch Tables. (line 81)
-* TARGET_UNWIND_INFO: Exception Region Output.
- (line 56)
-* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 936)
-* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55)
-* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 233)
-* TARGET_USE_JCR_SECTION: Misc. (line 918)
-* TARGET_USE_LOCAL_THUNK_ALIAS_P: Misc. (line 853)
-* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 129)
-* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 59)
-* TARGET_VALID_OPTION_ATTRIBUTE_P: Target Attributes. (line 93)
-* TARGET_VALID_POINTER_MODE: Register Arguments. (line 284)
-* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 302)
-* TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 479)
-* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 300)
-* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 249)
-* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN: Addressing Modes. (line 275)
-* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD: Addressing Modes. (line 287)
-* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes.
- (line 315)
-* TARGET_VERSION: Run-time Target. (line 91)
-* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 288)
-* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 282)
-* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 271)
-* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 245)
-* targetm: Target Structure. (line 7)
-* targets, makefile: Makefile. (line 6)
-* TCmode: Machine Modes. (line 197)
-* TDmode: Machine Modes. (line 94)
-* 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 38)
-* TF_SIZE: Type Layout. (line 132)
-* TFmode: Machine Modes. (line 98)
-* THEN_CLAUSE: Function Bodies. (line 6)
-* THREAD_MODEL_SPEC: Driver. (line 225)
-* THROW_EXPR: Expression trees. (line 6)
-* THUNK_DECL: Declarations. (line 6)
-* THUNK_DELTA: Declarations. (line 6)
-* TImode: Machine Modes. (line 48)
-* TImode, in insn: Insns. (line 231)
-* tm.h macros: Target Macros. (line 6)
-* TQFmode: Machine Modes. (line 62)
-* TQmode: Machine Modes. (line 119)
-* TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 62)
-* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49)
-* TRAMPOLINE_SECTION: Trampolines. (line 40)
-* TRAMPOLINE_SIZE: Trampolines. (line 45)
-* TRAMPOLINE_TEMPLATE: Trampolines. (line 29)
-* trampolines for nested functions: Trampolines. (line 6)
-* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 124)
-* trap instruction pattern: Standard Names. (line 1374)
-* tree <1>: Macros and Functions.
- (line 6)
-* tree: Tree overview. (line 6)
-* Tree SSA: Tree SSA. (line 6)
-* tree_code <1>: GIMPLE_OMP_FOR. (line 83)
-* tree_code <2>: GIMPLE_COND. (line 21)
-* tree_code <3>: GIMPLE_ASSIGN. (line 41)
-* tree_code: Manipulating GIMPLE statements.
- (line 31)
-* TREE_CODE: Tree overview. (line 6)
-* TREE_FILENAME: Working with declarations.
- (line 14)
-* tree_int_cst_equal: Expression trees. (line 6)
-* TREE_INT_CST_HIGH: Expression trees. (line 6)
-* TREE_INT_CST_LOW: Expression trees. (line 6)
-* tree_int_cst_lt: Expression trees. (line 6)
-* TREE_LINENO: Working with declarations.
- (line 20)
-* TREE_LIST: Containers. (line 6)
-* TREE_OPERAND: Expression trees. (line 6)
-* TREE_PUBLIC: Function Basics. (line 6)
-* TREE_PURPOSE: Containers. (line 6)
-* TREE_STRING_LENGTH: Expression trees. (line 6)
-* TREE_STRING_POINTER: Expression trees. (line 6)
-* TREE_TYPE <1>: Expression trees. (line 6)
-* TREE_TYPE <2>: Function Basics. (line 171)
-* TREE_TYPE <3>: Working with declarations.
- (line 11)
-* TREE_TYPE: Types. (line 6)
-* TREE_VALUE: Containers. (line 6)
-* TREE_VEC: Containers. (line 6)
-* TREE_VEC_ELT: Containers. (line 6)
-* TREE_VEC_LENGTH: Containers. (line 6)
-* Trees: Trees. (line 6)
-* TRULY_NOOP_TRUNCATION: Misc. (line 177)
-* TRUNC_DIV_EXPR: Expression trees. (line 6)
-* TRUNC_MOD_EXPR: Expression trees. (line 6)
-* truncate: Conversions. (line 38)
-* truncMN2 instruction pattern: Standard Names. (line 821)
-* TRUTH_AND_EXPR: Expression trees. (line 6)
-* TRUTH_ANDIF_EXPR: Expression trees. (line 6)
-* TRUTH_NOT_EXPR: Expression trees. (line 6)
-* TRUTH_OR_EXPR: Expression trees. (line 6)
-* TRUTH_ORIF_EXPR: Expression trees. (line 6)
-* TRUTH_XOR_EXPR: Expression trees. (line 6)
-* TRY_BLOCK: Function Bodies. (line 6)
-* TRY_HANDLERS: Function Bodies. (line 6)
-* TRY_STMTS: Function Bodies. (line 6)
-* tstM instruction pattern: Standard Names. (line 661)
-* Tuple specific accessors: Tuple specific accessors.
- (line 6)
-* tuples: Tuple representation.
- (line 6)
-* type: Types. (line 6)
-* type declaration: Declarations. (line 6)
-* TYPE_ALIGN: Types. (line 6)
-* TYPE_ARG_TYPES: Types. (line 6)
-* TYPE_ASM_OP: Label Output. (line 55)
-* TYPE_ATTRIBUTES: Attributes. (line 25)
-* TYPE_BINFO: Classes. (line 6)
-* TYPE_BUILT_IN: Types. (line 83)
-* TYPE_CANONICAL: Types. (line 6)
-* TYPE_CONTEXT: Types. (line 6)
-* TYPE_DECL: Declarations. (line 6)
-* TYPE_FIELDS <1>: Classes. (line 6)
-* TYPE_FIELDS: Types. (line 6)
-* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 91)
-* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 76)
-* TYPE_HAS_MUTABLE_P: Classes. (line 81)
-* TYPE_HAS_NEW_OPERATOR: Classes. (line 88)
-* TYPE_MAIN_VARIANT: Types. (line 6)
-* TYPE_MAX_VALUE: Types. (line 6)
-* TYPE_METHOD_BASETYPE: Types. (line 6)
-* TYPE_METHODS: Classes. (line 6)
-* TYPE_MIN_VALUE: Types. (line 6)
-* TYPE_NAME: Types. (line 6)
-* TYPE_NOTHROW_P: Function Basics. (line 180)
-* TYPE_OFFSET_BASETYPE: Types. (line 6)
-* TYPE_OPERAND_FMT: Label Output. (line 66)
-* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 99)
-* TYPE_OVERLOADS_ARROW: Classes. (line 102)
-* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 95)
-* TYPE_POLYMORPHIC_P: Classes. (line 72)
-* TYPE_PRECISION: Types. (line 6)
-* TYPE_PTR_P: Types. (line 89)
-* TYPE_PTRFN_P: Types. (line 93)
-* TYPE_PTRMEM_P: Types. (line 6)
-* TYPE_PTROB_P: Types. (line 96)
-* TYPE_PTROBV_P: Types. (line 6)
-* TYPE_QUAL_CONST: Types. (line 6)
-* TYPE_QUAL_RESTRICT: Types. (line 6)
-* TYPE_QUAL_VOLATILE: Types. (line 6)
-* TYPE_RAISES_EXCEPTIONS: Function Basics. (line 175)
-* TYPE_SIZE: Types. (line 6)
-* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6)
-* TYPE_UNQUALIFIED: Types. (line 6)
-* TYPE_VFIELD: Classes. (line 6)
-* TYPENAME_TYPE: Types. (line 6)
-* TYPENAME_TYPE_FULLNAME: Types. (line 6)
-* TYPEOF_TYPE: Types. (line 6)
-* UDAmode: Machine Modes. (line 168)
-* udiv: Arithmetic. (line 125)
-* udivM3 instruction pattern: Standard Names. (line 222)
-* udivmodM4 instruction pattern: Standard Names. (line 428)
-* udot_prodM instruction pattern: Standard Names. (line 265)
-* UDQmode: Machine Modes. (line 136)
-* UHAmode: Machine Modes. (line 160)
-* UHQmode: Machine Modes. (line 128)
-* UINTMAX_TYPE: Type Layout. (line 224)
-* umaddMN4 instruction pattern: Standard Names. (line 375)
-* umax: Arithmetic. (line 144)
-* umaxM3 instruction pattern: Standard Names. (line 222)
-* umin: Arithmetic. (line 144)
-* uminM3 instruction pattern: Standard Names. (line 222)
-* umod: Arithmetic. (line 131)
-* umodM3 instruction pattern: Standard Names. (line 222)
-* umsubMN4 instruction pattern: Standard Names. (line 399)
-* umulhisi3 instruction pattern: Standard Names. (line 347)
-* umulM3_highpart instruction pattern: Standard Names. (line 361)
-* umulqihi3 instruction pattern: Standard Names. (line 347)
-* umulsidi3 instruction pattern: Standard Names. (line 347)
-* unchanging: Flags. (line 319)
-* unchanging, in call_insn: Flags. (line 19)
-* unchanging, in jump_insn, call_insn and insn: Flags. (line 39)
-* unchanging, in mem: Flags. (line 152)
-* unchanging, in subreg: Flags. (line 188)
-* unchanging, in symbol_ref: Flags. (line 10)
-* UNEQ_EXPR: Expression trees. (line 6)
-* UNGE_EXPR: Expression trees. (line 6)
-* UNGT_EXPR: Expression trees. (line 6)
-* UNION_TYPE <1>: Classes. (line 6)
-* UNION_TYPE: Types. (line 6)
-* unions, returning: Interface. (line 10)
-* UNITS_PER_SIMD_WORD: Storage Layout. (line 77)
-* UNITS_PER_WORD: Storage Layout. (line 67)
-* UNKNOWN_TYPE: Types. (line 6)
-* UNLE_EXPR: Expression trees. (line 6)
-* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49)
-* UNLT_EXPR: Expression trees. (line 6)
-* UNORDERED_EXPR: Expression trees. (line 6)
-* unshare_all_rtl: Sharing. (line 58)
-* unsigned division: Arithmetic. (line 125)
-* unsigned division with unsigned saturation: Arithmetic. (line 125)
-* unsigned greater than: Comparisons. (line 64)
-* unsigned less than: Comparisons. (line 68)
-* unsigned minimum and maximum: Arithmetic. (line 144)
-* 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 287)
-* unspec_volatile: Side Effects. (line 287)
-* untyped_call instruction pattern: Standard Names. (line 1012)
-* untyped_return instruction pattern: Standard Names. (line 1062)
-* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59)
-* update_ssa: SSA. (line 76)
-* update_stmt <1>: SSA Operands. (line 6)
-* update_stmt: Manipulating GIMPLE statements.
- (line 141)
-* update_stmt_if_modified: Manipulating GIMPLE statements.
- (line 144)
-* UQQmode: Machine Modes. (line 123)
-* US Software GOFAST, floating point emulation library: Library Calls.
- (line 44)
-* us_ashift: Arithmetic. (line 168)
-* us_minus: Arithmetic. (line 36)
-* us_mult: Arithmetic. (line 92)
-* us_neg: Arithmetic. (line 81)
-* us_plus: Arithmetic. (line 14)
-* US_SOFTWARE_GOFAST: Library Calls. (line 45)
-* us_truncate: Conversions. (line 48)
-* usaddM3 instruction pattern: Standard Names. (line 222)
-* USAmode: Machine Modes. (line 164)
-* usashlM3 instruction pattern: Standard Names. (line 431)
-* usdivM3 instruction pattern: Standard Names. (line 222)
-* use: Side Effects. (line 162)
-* USE_C_ALLOCA: Host Misc. (line 19)
-* USE_LD_AS_NEEDED: Driver. (line 198)
-* USE_LOAD_POST_DECREMENT: Costs. (line 165)
-* USE_LOAD_POST_INCREMENT: Costs. (line 160)
-* USE_LOAD_PRE_DECREMENT: Costs. (line 175)
-* USE_LOAD_PRE_INCREMENT: Costs. (line 170)
-* use_optype_d: Manipulating GIMPLE statements.
- (line 101)
-* use_param: GTY Options. (line 113)
-* use_paramN: GTY Options. (line 131)
-* use_params: GTY Options. (line 139)
-* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 185)
-* USE_STORE_POST_DECREMENT: Costs. (line 185)
-* USE_STORE_POST_INCREMENT: Costs. (line 180)
-* USE_STORE_PRE_DECREMENT: Costs. (line 195)
-* USE_STORE_PRE_INCREMENT: Costs. (line 190)
-* used: Flags. (line 337)
-* used, in symbol_ref: Flags. (line 215)
-* USER_LABEL_PREFIX: Instruction Output. (line 126)
-* USING_DECL: Declarations. (line 6)
-* USING_STMT: Function Bodies. (line 6)
-* usmaddMN4 instruction pattern: Standard Names. (line 383)
-* usmsubMN4 instruction pattern: Standard Names. (line 407)
-* usmulhisi3 instruction pattern: Standard Names. (line 351)
-* usmulM3 instruction pattern: Standard Names. (line 222)
-* usmulqihi3 instruction pattern: Standard Names. (line 351)
-* usmulsidi3 instruction pattern: Standard Names. (line 351)
-* usnegM2 instruction pattern: Standard Names. (line 449)
-* USQmode: Machine Modes. (line 132)
-* ussubM3 instruction pattern: Standard Names. (line 222)
-* usum_widenM3 instruction pattern: Standard Names. (line 275)
-* UTAmode: Machine Modes. (line 172)
-* UTQmode: Machine Modes. (line 140)
-* V in constraint: Simple Constraints. (line 43)
-* VA_ARG_EXPR: Expression trees. (line 6)
-* values, returned by functions: Scalar Return. (line 6)
-* VAR_DECL <1>: Expression trees. (line 6)
-* VAR_DECL: Declarations. (line 6)
-* varargs implementation: Varargs. (line 6)
-* variable: Declarations. (line 6)
-* vashlM3 instruction pattern: Standard Names. (line 445)
-* vashrM3 instruction pattern: Standard Names. (line 445)
-* vec_concat: Vector Operations. (line 25)
-* vec_duplicate: Vector Operations. (line 30)
-* VEC_EXTRACT_EVEN_EXPR: Expression trees. (line 6)
-* vec_extract_evenM instruction pattern: Standard Names. (line 176)
-* VEC_EXTRACT_ODD_EXPR: Expression trees. (line 6)
-* vec_extract_oddM instruction pattern: Standard Names. (line 183)
-* vec_extractM instruction pattern: Standard Names. (line 171)
-* vec_initM instruction pattern: Standard Names. (line 204)
-* VEC_INTERLEAVE_HIGH_EXPR: Expression trees. (line 6)
-* vec_interleave_highM instruction pattern: Standard Names. (line 190)
-* VEC_INTERLEAVE_LOW_EXPR: Expression trees. (line 6)
-* vec_interleave_lowM instruction pattern: Standard Names. (line 197)
-* VEC_LSHIFT_EXPR: Expression trees. (line 6)
-* vec_merge: Vector Operations. (line 11)
-* VEC_PACK_FIX_TRUNC_EXPR: Expression trees. (line 6)
-* VEC_PACK_SAT_EXPR: Expression trees. (line 6)
-* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 302)
-* vec_pack_ssat_M instruction pattern: Standard Names. (line 295)
-* VEC_PACK_TRUNC_EXPR: Expression trees. (line 6)
-* vec_pack_trunc_M instruction pattern: Standard Names. (line 288)
-* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 302)
-* vec_pack_usat_M instruction pattern: Standard Names. (line 295)
-* VEC_RSHIFT_EXPR: Expression trees. (line 6)
-* vec_select: Vector Operations. (line 19)
-* vec_setM instruction pattern: Standard Names. (line 166)
-* vec_shl_M instruction pattern: Standard Names. (line 282)
-* vec_shr_M instruction pattern: Standard Names. (line 282)
-* VEC_UNPACK_FLOAT_HI_EXPR: Expression trees. (line 6)
-* VEC_UNPACK_FLOAT_LO_EXPR: Expression trees. (line 6)
-* VEC_UNPACK_HI_EXPR: Expression trees. (line 6)
-* VEC_UNPACK_LO_EXPR: Expression trees. (line 6)
-* vec_unpacks_float_hi_M instruction pattern: Standard Names.
- (line 324)
-* vec_unpacks_float_lo_M instruction pattern: Standard Names.
- (line 324)
-* vec_unpacks_hi_M instruction pattern: Standard Names. (line 309)
-* vec_unpacks_lo_M instruction pattern: Standard Names. (line 309)
-* vec_unpacku_float_hi_M instruction pattern: Standard Names.
- (line 324)
-* vec_unpacku_float_lo_M instruction pattern: Standard Names.
- (line 324)
-* vec_unpacku_hi_M instruction pattern: Standard Names. (line 317)
-* vec_unpacku_lo_M instruction pattern: Standard Names. (line 317)
-* VEC_WIDEN_MULT_HI_EXPR: Expression trees. (line 6)
-* VEC_WIDEN_MULT_LO_EXPR: Expression trees. (line 6)
-* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 333)
-* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 333)
-* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 333)
-* vec_widen_umult_lo__M instruction pattern: Standard Names. (line 333)
-* vector: Containers. (line 6)
-* vector operations: Vector Operations. (line 6)
-* VECTOR_CST: Expression trees. (line 6)
-* VECTOR_STORE_FLAG_VALUE: Misc. (line 308)
-* 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)
-* vlshrM3 instruction pattern: Standard Names. (line 445)
-* VMS: Filesystem. (line 37)
-* VMS_DEBUGGING_INFO: VMS Debug. (line 9)
-* VOID_TYPE: Types. (line 6)
-* VOIDmode: Machine Modes. (line 190)
-* volatil: Flags. (line 351)
-* volatil, in insn, call_insn, jump_insn, code_label, 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 94)
-* volatil, in reg: Flags. (line 116)
-* volatil, in subreg: Flags. (line 188)
-* volatil, in symbol_ref: Flags. (line 224)
-* volatile memory references: Flags. (line 352)
-* voptype_d: Manipulating GIMPLE statements.
- (line 108)
-* voting between constraint alternatives: Class Preferences. (line 6)
-* vrotlM3 instruction pattern: Standard Names. (line 445)
-* vrotrM3 instruction pattern: Standard Names. (line 445)
-* walk_dominator_tree: SSA. (line 256)
-* walk_gimple_op: Statement and operand traversals.
- (line 32)
-* walk_gimple_seq: Statement and operand traversals.
- (line 50)
-* walk_gimple_stmt: Statement and operand traversals.
- (line 13)
-* walk_use_def_chains: SSA. (line 232)
-* WCHAR_TYPE: Type Layout. (line 192)
-* WCHAR_TYPE_SIZE: Type Layout. (line 200)
-* which_alternative: Output Statement. (line 59)
-* WHILE_BODY: Function Bodies. (line 6)
-* WHILE_COND: Function Bodies. (line 6)
-* WHILE_STMT: Function Bodies. (line 6)
-* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 147)
-* WINT_TYPE: Type Layout. (line 205)
-* word_mode: Machine Modes. (line 336)
-* WORD_REGISTER_OPERATIONS: Misc. (line 63)
-* WORD_SWITCH_TAKES_ARG: Driver. (line 20)
-* WORDS_BIG_ENDIAN: Storage Layout. (line 29)
-* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217)
-* X in constraint: Simple Constraints. (line 114)
-* x-HOST: Host Fragment. (line 6)
-* XCmode: Machine Modes. (line 197)
-* XCOFF_DEBUGGING_INFO: DBX Options. (line 13)
-* XEXP: Accessors. (line 6)
-* XF_SIZE: Type Layout. (line 131)
-* XFmode: Machine Modes. (line 79)
-* XINT: Accessors. (line 6)
-* xm-MACHINE.h <1>: Host Misc. (line 6)
-* xm-MACHINE.h: Filesystem. (line 6)
-* xor: Arithmetic. (line 163)
-* xor, canonicalization of: Insn Canonicalizations.
- (line 84)
-* xorM3 instruction pattern: Standard Names. (line 222)
-* 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 831)
-* zero_extract: Bit-Fields. (line 30)
-* zero_extract, canonicalization of: Insn Canonicalizations.
- (line 96)
-
-
-\1f
-Tag Table:
-Node: Top\7f2034
-Node: Contributing\7f5059
-Node: Portability\7f5800
-Node: Interface\7f7588
-Node: Libgcc\7f10628
-Node: Integer library routines\7f12469
-Node: Soft float library routines\7f19308
-Node: Decimal float library routines\7f31245
-Node: Fixed-point fractional library routines\7f47002
-Node: Exception handling routines\7f147400
-Node: Miscellaneous routines\7f148507
-Node: Languages\7f148890
-Node: Source Tree\7f150437
-Node: Configure Terms\7f151056
-Node: Top Level\7f154014
-Node: gcc Directory\7f156784
-Node: Subdirectories\7f157753
-Node: Configuration\7f159603
-Node: Config Fragments\7f160323
-Node: System Config\7f161552
-Node: Configuration Files\7f162488
-Node: Build\7f165063
-Node: Makefile\7f165475
-Ref: Makefile-Footnote-1\7f172193
-Ref: Makefile-Footnote-2\7f172338
-Node: Library Files\7f172410
-Node: Headers\7f172972
-Node: Documentation\7f175055
-Node: Texinfo Manuals\7f175914
-Node: Man Page Generation\7f178252
-Node: Miscellaneous Docs\7f180167
-Node: Front End\7f181466
-Node: Front End Directory\7f185167
-Node: Front End Config\7f190289
-Node: Back End\7f193203
-Node: Testsuites\7f196880
-Node: Test Idioms\7f197744
-Node: Test Directives\7f201145
-Node: Ada Tests\7f213209
-Node: C Tests\7f214501
-Node: libgcj Tests\7f218856
-Node: gcov Testing\7f219988
-Node: profopt Testing\7f222972
-Node: compat Testing\7f224415
-Node: Torture Tests\7f228659
-Node: Options\7f230291
-Node: Option file format\7f230732
-Node: Option properties\7f233481
-Node: Passes\7f239537
-Node: Parsing pass\7f240279
-Node: Gimplification pass\7f243807
-Node: Pass manager\7f245634
-Node: Tree SSA passes\7f247116
-Node: RTL passes\7f268942
-Node: Trees\7f281285
-Node: Deficiencies\7f284015
-Node: Tree overview\7f284252
-Node: Macros and Functions\7f288375
-Node: Identifiers\7f288521
-Node: Containers\7f290046
-Node: Types\7f291201
-Node: Scopes\7f306904
-Node: Namespaces\7f307666
-Node: Classes\7f310478
-Node: Declarations\7f315235
-Node: Working with declarations\7f315730
-Node: Internal structure\7f322187
-Node: Current structure hierarchy\7f322569
-Node: Adding new DECL node types\7f324661
-Node: Functions\7f328732
-Node: Function Basics\7f331135
-Node: Function Bodies\7f338865
-Node: Attributes\7f350107
-Node: Expression trees\7f351348
-Node: RTL\7f393957
-Node: RTL Objects\7f396075
-Node: RTL Classes\7f399949
-Node: Accessors\7f404901
-Node: Special Accessors\7f407295
-Node: Flags\7f412513
-Node: Machine Modes\7f428381
-Node: Constants\7f440697
-Node: Regs and Memory\7f446726
-Node: Arithmetic\7f464627
-Node: Comparisons\7f474147
-Node: Bit-Fields\7f478439
-Node: Vector Operations\7f479991
-Node: Conversions\7f481617
-Node: RTL Declarations\7f486115
-Node: Side Effects\7f486936
-Node: Incdec\7f503259
-Node: Assembler\7f506594
-Node: Insns\7f508126
-Node: Calls\7f532015
-Node: Sharing\7f534608
-Node: Reading RTL\7f537718
-Node: GENERIC\7f538708
-Node: Statements\7f540347
-Node: Blocks\7f540792
-Node: Statement Sequences\7f542045
-Node: Empty Statements\7f542378
-Node: Jumps\7f542952
-Node: Cleanups\7f543605
-Node: GIMPLE\7f545358
-Node: Tuple representation\7f548979
-Node: GIMPLE instruction set\7f557634
-Node: GIMPLE Exception Handling\7f559302
-Node: Temporaries\7f561217
-Ref: Temporaries-Footnote-1\7f562536
-Node: Operands\7f562599
-Node: Compound Expressions\7f563373
-Node: Compound Lvalues\7f563607
-Node: Conditional Expressions\7f564373
-Node: Logical Operators\7f565043
-Node: Manipulating GIMPLE statements\7f571134
-Node: Tuple specific accessors\7f577062
-Node: `GIMPLE_ASM'\7f577895
-Node: `GIMPLE_ASSIGN'\7f580500
-Node: `GIMPLE_BIND'\7f584446
-Node: `GIMPLE_CALL'\7f586253
-Node: `GIMPLE_CATCH'\7f590512
-Node: `GIMPLE_CHANGE_DYNAMIC_TYPE'\7f591670
-Node: `GIMPLE_COND'\7f593003
-Node: `GIMPLE_EH_FILTER'\7f595809
-Node: `GIMPLE_LABEL'\7f597295
-Node: `GIMPLE_NOP'\7f598270
-Node: `GIMPLE_OMP_ATOMIC_LOAD'\7f598639
-Node: `GIMPLE_OMP_ATOMIC_STORE'\7f599549
-Node: `GIMPLE_OMP_CONTINUE'\7f600188
-Node: `GIMPLE_OMP_CRITICAL'\7f601538
-Node: `GIMPLE_OMP_FOR'\7f602474
-Node: `GIMPLE_OMP_MASTER'\7f605984
-Node: `GIMPLE_OMP_ORDERED'\7f606367
-Node: `GIMPLE_OMP_PARALLEL'\7f606767
-Node: `GIMPLE_OMP_RETURN'\7f609536
-Node: `GIMPLE_OMP_SECTION'\7f610186
-Node: `GIMPLE_OMP_SECTIONS'\7f610852
-Node: `GIMPLE_OMP_SINGLE'\7f612456
-Node: `GIMPLE_PHI'\7f613392
-Node: `GIMPLE_RESX'\7f614805
-Node: `GIMPLE_RETURN'\7f615524
-Node: `GIMPLE_SWITCH'\7f616092
-Node: `GIMPLE_TRY'\7f618222
-Node: `GIMPLE_WITH_CLEANUP_EXPR'\7f620012
-Node: GIMPLE sequences\7f620895
-Node: Sequence iterators\7f624101
-Node: Adding a new GIMPLE statement code\7f632556
-Node: Statement and operand traversals\7f633836
-Node: Tree SSA\7f636446
-Node: Annotations\7f638166
-Node: SSA Operands\7f638692
-Node: SSA\7f653223
-Node: Alias analysis\7f665514
-Node: Loop Analysis and Representation\7f672970
-Node: Loop representation\7f674151
-Node: Loop querying\7f681071
-Node: Loop manipulation\7f683904
-Node: LCSSA\7f686272
-Node: Scalar evolutions\7f688344
-Node: loop-iv\7f691588
-Node: Number of iterations\7f693514
-Node: Dependency analysis\7f696323
-Node: Lambda\7f702691
-Node: Omega\7f704361
-Node: Control Flow\7f705926
-Node: Basic Blocks\7f706921
-Node: Edges\7f711489
-Node: Profile information\7f720051
-Node: Maintaining the CFG\7f724737
-Node: Liveness information\7f731619
-Node: Machine Desc\7f733746
-Node: Overview\7f736214
-Node: Patterns\7f738255
-Node: Example\7f741693
-Node: RTL Template\7f743128
-Node: Output Template\7f753783
-Node: Output Statement\7f757749
-Node: Predicates\7f761711
-Node: Machine-Independent Predicates\7f764629
-Node: Defining Predicates\7f769261
-Node: Constraints\7f775226
-Node: Simple Constraints\7f776474
-Node: Multi-Alternative\7f788680
-Node: Class Preferences\7f791521
-Node: Modifiers\7f792413
-Node: Machine Constraints\7f796545
-Node: Disable Insn Alternatives\7f829268
-Node: Define Constraints\7f832161
-Node: C Constraint Interface\7f838941
-Node: Standard Names\7f842582
-Ref: shift patterns\7f861510
-Ref: prologue instruction pattern\7f902528
-Ref: epilogue instruction pattern\7f903021
-Node: Pattern Ordering\7f912520
-Node: Dependent Patterns\7f913756
-Node: Jump Patterns\7f916570
-Node: Looping Patterns\7f922266
-Node: Insn Canonicalizations\7f926994
-Node: Expander Definitions\7f931378
-Node: Insn Splitting\7f939496
-Node: Including Patterns\7f949099
-Node: Peephole Definitions\7f950879
-Node: define_peephole\7f952132
-Node: define_peephole2\7f958463
-Node: Insn Attributes\7f961530
-Node: Defining Attributes\7f962636
-Node: Expressions\7f965156
-Node: Tagging Insns\7f971758
-Node: Attr Example\7f976111
-Node: Insn Lengths\7f978485
-Node: Constant Attributes\7f981544
-Node: Delay Slots\7f982713
-Node: Processor pipeline description\7f985937
-Ref: Processor pipeline description-Footnote-1\7f1003303
-Node: Conditional Execution\7f1003625
-Node: Constant Definitions\7f1006478
-Node: Iterators\7f1008073
-Node: Mode Iterators\7f1008520
-Node: Defining Mode Iterators\7f1009498
-Node: Substitutions\7f1010992
-Node: Examples\7f1013233
-Node: Code Iterators\7f1014681
-Node: Target Macros\7f1016938
-Node: Target Structure\7f1019961
-Node: Driver\7f1021230
-Node: Run-time Target\7f1044911
-Node: Per-Function Data\7f1052035
-Node: Storage Layout\7f1054798
-Node: Type Layout\7f1080212
-Node: Registers\7f1093169
-Node: Register Basics\7f1094143
-Node: Allocation Order\7f1099710
-Node: Values in Registers\7f1101731
-Node: Leaf Functions\7f1109220
-Node: Stack Registers\7f1112078
-Node: Register Classes\7f1113194
-Node: Old Constraints\7f1139906
-Node: Stack and Calling\7f1147057
-Node: Frame Layout\7f1147591
-Node: Exception Handling\7f1158437
-Node: Stack Checking\7f1164815
-Node: Frame Registers\7f1169202
-Node: Elimination\7f1175808
-Node: Stack Arguments\7f1179839
-Node: Register Arguments\7f1186642
-Node: Scalar Return\7f1202090
-Node: Aggregate Return\7f1207636
-Node: Caller Saves\7f1211295
-Node: Function Entry\7f1212473
-Node: Profiling\7f1225088
-Node: Tail Calls\7f1226787
-Node: Stack Smashing Protection\7f1228154
-Node: Varargs\7f1229266
-Node: Trampolines\7f1237226
-Node: Library Calls\7f1243892
-Node: Addressing Modes\7f1248742
-Node: Anchored Addresses\7f1264660
-Node: Condition Code\7f1267321
-Node: Costs\7f1275610
-Node: Scheduling\7f1288709
-Node: Sections\7f1307270
-Node: PIC\7f1321920
-Node: Assembler Format\7f1323910
-Node: File Framework\7f1325048
-Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS\7f1329954
-Node: Data Output\7f1333220
-Node: Uninitialized Data\7f1340979
-Node: Label Output\7f1346050
-Node: Initialization\7f1367717
-Node: Macros for Initialization\7f1373679
-Node: Instruction Output\7f1380131
-Node: Dispatch Tables\7f1389125
-Node: Exception Region Output\7f1392920
-Node: Alignment Output\7f1398680
-Node: Debugging Info\7f1402843
-Node: All Debuggers\7f1403513
-Node: DBX Options\7f1406368
-Node: DBX Hooks\7f1411817
-Node: File Names and DBX\7f1413743
-Node: SDB and DWARF\7f1415854
-Node: VMS Debug\7f1419846
-Node: Floating Point\7f1420416
-Node: Mode Switching\7f1425239
-Node: Target Attributes\7f1429165
-Node: Emulated TLS\7f1435929
-Node: MIPS Coprocessors\7f1439319
-Node: PCH Target\7f1440888
-Node: C++ ABI\7f1442409
-Node: Misc\7f1447028
-Ref: TARGET_SHIFT_TRUNCATION_MASK\7f1454398
-Node: Host Config\7f1494951
-Node: Host Common\7f1496019
-Node: Filesystem\7f1498398
-Node: Host Misc\7f1502513
-Node: Fragments\7f1504652
-Node: Target Fragment\7f1505847
-Node: Host Fragment\7f1511737
-Node: Collect2\7f1511977
-Node: Header Dirs\7f1514520
-Node: Type Information\7f1515943
-Node: GTY Options\7f1518234
-Node: GGC Roots\7f1528909
-Node: Files\7f1529629
-Node: Invoking the garbage collector\7f1532093
-Node: Funding\7f1533146
-Node: GNU Project\7f1535642
-Node: Copying\7f1536291
-Node: GNU Free Documentation License\7f1573822
-Node: Contributors\7f1596231
-Node: Option Index\7f1632561
-Node: Concept Index\7f1633146
-\1f
-End Tag Table
+++ /dev/null
-This is doc/gcj.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/gcc/java/gcj.texi.
-
-Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-File: gcj.info, Node: GNU Free Documentation License, Next: Invoking gcj, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-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
-
-\1f
-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.)
-
-\1f
-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'.
-
-\1f
-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.
-
-\1f
-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'.
-
-\1f
-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'
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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::
-
-\1f
-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.
-
-\1f
-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.
-
-
-\1f
-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'.
-
-\1f
-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'.
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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++.
-
-\1f
-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.
-
-\1f
-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;
-
-\1f
-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
-
-
-\1f
-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$);
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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++.
-
-\1f
-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);
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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::.
-
-\1f
-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.
-
-\1f
-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()'.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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();
- }
- }
-
-\1f
-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.
-
-\1f
-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'
-
-\1f
-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.
-
-
-\1f
-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'.
-
-
-\1f
-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'.
-
-
-\1f
-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 the online documentation at
-`http://java.sun.com/'.
-
- 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://sources.redhat.com/mauve/'
-for more information.
-
-\1f
-File: gcj.info, Node: Index, Prev: Resources, Up: Top
-
-Index
-*****
-
-\0\b[index\0\b]
-* Menu:
-
-* class path: Input Options. (line 6)
-* class$: Reference types. (line 20)
-* elements on template<class T>: Arrays. (line 46)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* GCJ_PROPERTIES: Extensions. (line 56)
-* jclass: Reference types. (line 16)
-* jobject: Reference types. (line 16)
-* jstring: Reference types. (line 16)
-* JvAllocBytes: Mixing with C++. (line 99)
-* JvAttachCurrentThread: Invocation. (line 55)
-* JvCreateJavaVM: Invocation. (line 11)
-* JvDetachCurrentThread: Invocation. (line 68)
-* JvFree: Memory allocation. (line 19)
-* JvGetArrayLength: Arrays. (line 86)
-* JvGetStringChars: Strings. (line 25)
-* JvGetStringUTFLength: Strings. (line 29)
-* JvGetStringUTFRegion: Strings. (line 34)
-* JvMalloc: Memory allocation. (line 11)
-* JvNewBooleanArray: Arrays. (line 83)
-* JvNewObjectArray: Arrays. (line 57)
-* JvNewString: Strings. (line 11)
-* JvNewStringLatin1: Strings. (line 15)
-* JvNewStringUTF: Strings. (line 21)
-* JvPrimClass: Primitive types. (line 36)
-* JvRealloc: Memory allocation. (line 15)
-
-
-\1f
-Tag Table:
-Node: Top\7f2789
-Node: Copying\7f4208
-Node: GNU Free Documentation License\7f41758
-Node: Invoking gcj\7f64170
-Node: Input and output files\7f64933
-Node: Input Options\7f66459
-Node: Encodings\7f69733
-Node: Warnings\7f70939
-Node: Linking\7f72052
-Node: Code Generation\7f74991
-Node: Configure-time Options\7f81771
-Node: Compatibility\7f83194
-Node: Limitations\7f83678
-Node: Extensions\7f85260
-Node: Invoking jcf-dump\7f88354
-Node: Invoking gij\7f89299
-Node: Invoking gcj-dbtool\7f92550
-Node: Invoking jv-convert\7f95016
-Node: Invoking grmic\7f96095
-Node: Invoking gc-analyze\7f97481
-Node: Invoking aot-compile\7f98922
-Node: Invoking rebuild-gcj-db\7f99871
-Node: About CNI\7f100181
-Node: Basic concepts\7f101640
-Node: Packages\7f104536
-Node: Primitive types\7f106864
-Node: Reference types\7f108542
-Node: Interfaces\7f109631
-Node: Objects and Classes\7f110542
-Node: Class Initialization\7f112737
-Node: Object allocation\7f115079
-Node: Memory allocation\7f115869
-Node: Arrays\7f116501
-Node: Methods\7f119311
-Node: Strings\7f122132
-Node: Mixing with C++\7f123636
-Node: Exception Handling\7f127107
-Node: Synchronization\7f128741
-Node: Invocation\7f130731
-Node: Reflection\7f135667
-Node: System properties\7f136128
-Node: Standard Properties\7f137005
-Node: GNU Classpath Properties\7f141437
-Node: libgcj Runtime Properties\7f142484
-Node: Resources\7f146986
-Node: Index\7f147824
-\1f
-End Tag Table
+++ /dev/null
-This is ../../gmp/doc/gmp.info, produced by makeinfo version 4.8 from
-../../gmp/doc/gmp.texi.
-
- This manual describes how to install and use the GNU multiple
-precision arithmetic library, version 4.3.1.
-
- Copyright 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.2 or any later version published by the Free Software Foundation;
-with no Invariant Sections, with the Front-Cover Texts being "A GNU
-Manual", and with the Back-Cover Texts being "You have freedom to copy
-and modify this GNU Manual, like GNU software". A copy of the license
-is included in *Note GNU Free Documentation License::.
-
-INFO-DIR-SECTION GNU libraries
-START-INFO-DIR-ENTRY
-* gmp: (gmp). GNU Multiple Precision Arithmetic Library.
-END-INFO-DIR-ENTRY
-
-\1f
-Indirect:
-gmp.info-1: 975
-gmp.info-2: 300713
-\1f
-Tag Table:
-(Indirect)
-Node: Top\7f975
-Node: Copying\7f3199
-Node: Introduction to GMP\7f5050
-Node: Installing GMP\7f7761
-Node: Build Options\7f8493
-Node: ABI and ISA\7f24561
-Node: Notes for Package Builds\7f34239
-Node: Notes for Particular Systems\7f37326
-Node: Known Build Problems\7f44085
-Node: Performance optimization\7f47619
-Node: GMP Basics\7f48753
-Node: Headers and Libraries\7f49401
-Node: Nomenclature and Types\7f50825
-Node: Function Classes\7f52533
-Node: Variable Conventions\7f54226
-Node: Parameter Conventions\7f55835
-Node: Memory Management\7f57891
-Node: Reentrancy\7f59019
-Node: Useful Macros and Constants\7f60892
-Node: Compatibility with older versions\7f61751
-Node: Demonstration Programs\7f62712
-Node: Efficiency\7f64577
-Node: Debugging\7f72201
-Node: Profiling\7f78759
-Node: Autoconf\7f82750
-Node: Emacs\7f84529
-Node: Reporting Bugs\7f85135
-Node: Integer Functions\7f87678
-Node: Initializing Integers\7f88454
-Node: Assigning Integers\7f90125
-Node: Simultaneous Integer Init & Assign\7f91712
-Node: Converting Integers\7f93337
-Node: Integer Arithmetic\7f96259
-Node: Integer Division\7f97861
-Node: Integer Exponentiation\7f104289
-Node: Integer Roots\7f105150
-Node: Number Theoretic Functions\7f106824
-Node: Integer Comparisons\7f112983
-Node: Integer Logic and Bit Fiddling\7f114361
-Node: I/O of Integers\7f116984
-Node: Integer Random Numbers\7f119868
-Node: Integer Import and Export\7f122491
-Node: Miscellaneous Integer Functions\7f126494
-Node: Integer Special Functions\7f128354
-Node: Rational Number Functions\7f131441
-Node: Initializing Rationals\7f132634
-Node: Rational Conversions\7f134879
-Node: Rational Arithmetic\7f136610
-Node: Comparing Rationals\7f137946
-Node: Applying Integer Functions\7f139313
-Node: I/O of Rationals\7f140796
-Node: Floating-point Functions\7f142656
-Node: Initializing Floats\7f145541
-Node: Assigning Floats\7f149238
-Node: Simultaneous Float Init & Assign\7f151805
-Node: Converting Floats\7f153333
-Node: Float Arithmetic\7f156581
-Node: Float Comparison\7f158626
-Node: I/O of Floats\7f160213
-Node: Miscellaneous Float Functions\7f162811
-Node: Low-level Functions\7f164711
-Node: Random Number Functions\7f186371
-Node: Random State Initialization\7f187439
-Node: Random State Seeding\7f190301
-Node: Random State Miscellaneous\7f191690
-Node: Formatted Output\7f192331
-Node: Formatted Output Strings\7f192576
-Node: Formatted Output Functions\7f197790
-Node: C++ Formatted Output\7f201865
-Node: Formatted Input\7f204547
-Node: Formatted Input Strings\7f204783
-Node: Formatted Input Functions\7f209435
-Node: C++ Formatted Input\7f212404
-Node: C++ Class Interface\7f214307
-Node: C++ Interface General\7f215308
-Node: C++ Interface Integers\7f218378
-Node: C++ Interface Rationals\7f221809
-Node: C++ Interface Floats\7f225486
-Node: C++ Interface Random Numbers\7f230778
-Node: C++ Interface Limitations\7f233184
-Node: BSD Compatible Functions\7f236004
-Node: Custom Allocation\7f240715
-Node: Language Bindings\7f245033
-Node: Algorithms\7f248986
-Node: Multiplication Algorithms\7f249686
-Node: Basecase Multiplication\7f250664
-Node: Karatsuba Multiplication\7f252572
-Node: Toom 3-Way Multiplication\7f256200
-Node: Toom 4-Way Multiplication\7f262614
-Node: FFT Multiplication\7f263986
-Node: Other Multiplication\7f269322
-Node: Unbalanced Multiplication\7f271796
-Node: Division Algorithms\7f272587
-Node: Single Limb Division\7f272934
-Node: Basecase Division\7f275853
-Node: Divide and Conquer Division\7f277056
-Node: Exact Division\7f279293
-Node: Exact Remainder\7f282460
-Node: Small Quotient Division\7f284752
-Node: Greatest Common Divisor Algorithms\7f286350
-Node: Binary GCD\7f286647
-Node: Lehmer's Algorithm\7f289496
-Node: Subquadratic GCD\7f291716
-Node: Extended GCD\7f294175
-Node: Jacobi Symbol\7f295487
-Node: Powering Algorithms\7f296403
-Node: Normal Powering Algorithm\7f296666
-Node: Modular Powering Algorithm\7f297194
-Node: Root Extraction Algorithms\7f298257
-Node: Square Root Algorithm\7f298572
-Node: Nth Root Algorithm\7f300713
-Node: Perfect Square Algorithm\7f301498
-Node: Perfect Power Algorithm\7f303584
-Node: Radix Conversion Algorithms\7f304205
-Node: Binary to Radix\7f304581
-Node: Radix to Binary\7f308510
-Node: Other Algorithms\7f310598
-Node: Prime Testing Algorithm\7f310950
-Node: Factorial Algorithm\7f312134
-Node: Binomial Coefficients Algorithm\7f313537
-Node: Fibonacci Numbers Algorithm\7f314431
-Node: Lucas Numbers Algorithm\7f316905
-Node: Random Number Algorithms\7f317626
-Node: Assembly Coding\7f319747
-Node: Assembly Code Organisation\7f320707
-Node: Assembly Basics\7f321674
-Node: Assembly Carry Propagation\7f322824
-Node: Assembly Cache Handling\7f324655
-Node: Assembly Functional Units\7f326816
-Node: Assembly Floating Point\7f328429
-Node: Assembly SIMD Instructions\7f332206
-Node: Assembly Software Pipelining\7f333188
-Node: Assembly Loop Unrolling\7f334250
-Node: Assembly Writing Guide\7f336465
-Node: Internals\7f339230
-Node: Integer Internals\7f339742
-Node: Rational Internals\7f341998
-Node: Float Internals\7f343236
-Node: Raw Output Internals\7f350650
-Node: C++ Interface Internals\7f351844
-Node: Contributors\7f355142
-Node: References\7f359690
-Node: GNU Free Documentation License\7f364930
-Node: Concept Index\7f387376
-Node: Function Index\7f433848
-\1f
-End Tag Table
+++ /dev/null
-This is libgomp.info, produced by makeinfo version 4.13 from
-/d/gcc-4.4.3/gcc-4.4.3/libgomp/libgomp.texi.
-
-Copyright (C) 2006, 2007, 2008 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.2 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 GNU Libraries
-START-INFO-DIR-ENTRY
-* libgomp: (libgomp). GNU OpenMP runtime library
-END-INFO-DIR-ENTRY
-
- This manual documents the GNU implementation of the OpenMP API for
-multi-platform shared-memory parallel programming in C/C++ and Fortran.
-
- Published by the Free Software Foundation 51 Franklin Street, Fifth
-Floor Boston, MA 02110-1301 USA
-
- Copyright (C) 2006, 2007, 2008 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.2 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.
-
-\1f
-File: libgomp.info, Node: Top, Next: Enabling OpenMP, Up: (dir)
-
-Introduction
-************
-
-This manual documents the usage of libgomp, the GNU implementation of
-the OpenMP (http://www.openmp.org) Application Programming Interface
-(API) for multi-platform shared-memory parallel programming in C/C++
-and Fortran.
-
-* Menu:
-
-* Enabling OpenMP:: How to enable OpenMP for your applications.
-* Runtime Library Routines:: The OpenMP runtime application programming
- interface.
-* Environment Variables:: Influencing runtime behavior with environment
- variables.
-* The libgomp ABI:: Notes on the external ABI presented by libgomp.
-* Reporting Bugs:: How to report bugs in GNU OpenMP.
-* Copying:: GNU general public license says
- how you can copy and share libgomp.
-* GNU Free Documentation License::
- How you can copy and share this manual.
-* Funding:: How to help assure continued work for free
- software.
-* Index:: Index of this documentation.
-
-\1f
-File: libgomp.info, Node: Enabling OpenMP, Next: Runtime Library Routines, Prev: Top, Up: Top
-
-1 Enabling OpenMP
-*****************
-
-To activate the OpenMP extensions for C/C++ and Fortran, the
-compile-time flag `-fopenmp' must be specified. This enables the OpenMP
-directive `#pragma omp' in C/C++ and `!$omp' directives in free form,
-`c$omp', `*$omp' and `!$omp' directives in fixed form, `!$' conditional
-compilation sentinels in free form and `c$', `*$' and `!$' sentinels in
-fixed form, for Fortran. The flag also arranges for automatic linking
-of the OpenMP runtime library (*note Runtime Library Routines::).
-
- A complete description of all OpenMP directives accepted may be
-found in the OpenMP Application Program Interface
-(http://www.openmp.org) manual, version 3.0.
-
-\1f
-File: libgomp.info, Node: Runtime Library Routines, Next: Environment Variables, Prev: Enabling OpenMP, Up: Top
-
-2 Runtime Library Routines
-**************************
-
-The runtime routines described here are defined by section 3 of the
-OpenMP specifications in version 3.0. The routines are structured in
-following three parts:
-
- Control threads, processors and the parallel environment.
-
-* Menu:
-
-* omp_get_active_level:: Number of active parallel regions
-* omp_get_ancestor_thread_num:: Ancestor thread ID
-* omp_get_dynamic:: Dynamic teams setting
-* omp_get_level:: Number of parallel regions
-* omp_get_max_active_levels:: Maximal number of active regions
-* omp_get_max_threads:: Maximal number of threads of parallel region
-* omp_get_nested:: Nested parallel regions
-* omp_get_num_procs:: Number of processors online
-* omp_get_num_threads:: Size of the active team
-* omp_get_schedule:: Obtain the runtime scheduling method
-* omp_get_team_size:: Number of threads in a team
-* omp_get_thread_limit:: Maximal number of threads
-* omp_get_thread_num:: Current thread ID
-* omp_in_parallel:: Whether a parallel region is active
-* omp_set_dynamic:: Enable/disable dynamic teams
-* omp_set_max_active_levels:: Limits the number of active parallel regions
-* omp_set_nested:: Enable/disable nested parallel regions
-* omp_set_num_threads:: Set upper team size limit
-* omp_set_schedule:: Set the runtime scheduling method
-
- Initialize, set, test, unset and destroy simple and nested locks.
-
-* Menu:
-
-* omp_init_lock:: Initialize simple lock
-* omp_set_lock:: Wait for and set simple lock
-* omp_test_lock:: Test and set simple lock if available
-* omp_unset_lock:: Unset simple lock
-* omp_destroy_lock:: Destroy simple lock
-* omp_init_nest_lock:: Initialize nested lock
-* omp_set_nest_lock:: Wait for and set simple lock
-* omp_test_nest_lock:: Test and set nested lock if available
-* omp_unset_nest_lock:: Unset nested lock
-* omp_destroy_nest_lock:: Destroy nested lock
-
- Portable, thread-based, wall clock timer.
-
-* Menu:
-
-* omp_get_wtick:: Get timer precision.
-* omp_get_wtime:: Elapsed wall clock time.
-
-\1f
-File: libgomp.info, Node: omp_get_active_level, Next: omp_get_ancestor_thread_num, Up: Runtime Library Routines
-
-2.1 `omp_get_active_level' - Number of parallel regions
-=======================================================
-
-_Description_:
- This function returns the nesting level for the active parallel
- blocks, which enclose the calling call.
-
-_C/C++_
- _Prototype_: `int omp_get_active_level();'
-
-_Fortran_:
- _Interface_: `integer omp_get_active_level()'
-
-_See also_:
- *note omp_get_level::, *note omp_get_max_active_levels::, *note
- omp_set_max_active_levels::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.19.
-
-\1f
-File: libgomp.info, Node: omp_get_ancestor_thread_num, Next: omp_get_dynamic, Prev: omp_get_active_level, Up: Runtime Library Routines
-
-2.2 `omp_get_ancestor_thread_num' - Ancestor thread ID
-======================================================
-
-_Description_:
- This function returns the thread identification number for the
- given nesting level of the current thread. For values of LEVEL
- outside zero to `omp_get_level' -1 is returned; if LEVEL is
- `omp_get_level' the result is identical to `omp_get_thread_num'.
-
-_C/C++_
- _Prototype_: `int omp_get_ancestor_thread_num(int level);'
-
-_Fortran_:
- _Interface_: `integer omp_ancestor_thread_num(level)'
- `integer level'
-
-_See also_:
- *note omp_get_level::, *note omp_get_thread_num::, *note
- omp_get_team_size::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.17.
-
-\1f
-File: libgomp.info, Node: omp_get_dynamic, Next: omp_get_level, Prev: omp_get_ancestor_thread_num, Up: Runtime Library Routines
-
-2.3 `omp_get_dynamic' - Dynamic teams setting
-=============================================
-
-_Description_:
- This function returns `true' if enabled, `false' otherwise. Here,
- `true' and `false' represent their language-specific counterparts.
-
- The dynamic team setting may be initialized at startup by the
- `OMP_DYNAMIC' environment variable or at runtime using
- `omp_set_dynamic'. If undefined, dynamic adjustment is disabled by
- default.
-
-_C/C++_:
- _Prototype_: `int omp_get_dynamic();'
-
-_Fortran_:
- _Interface_: `logical function omp_get_dynamic()'
-
-_See also_:
- *note omp_set_dynamic::, *note OMP_DYNAMIC::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.8.
-
-\1f
-File: libgomp.info, Node: omp_get_level, Next: omp_get_max_active_levels, Prev: omp_get_dynamic, Up: Runtime Library Routines
-
-2.4 `omp_get_level' - Obtain the current nesting level
-======================================================
-
-_Description_:
- This function returns the nesting level for the parallel blocks,
- which enclose the calling call.
-
-_C/C++_
- _Prototype_: `int omp_get level();'
-
-_Fortran_:
- _Interface_: `integer omp_level()'
-
-_See also_:
- *note omp_get_active_level::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.16.
-
-\1f
-File: libgomp.info, Node: omp_get_max_active_levels, Next: omp_get_max_threads, Prev: omp_get_level, Up: Runtime Library Routines
-
-2.5 `omp_set_max_active_levels' - Maximal number of active regions
-==================================================================
-
-_Description_:
- This function obtains the maximally allowed number of nested,
- active parallel regions.
-
-_C/C++_
- _Prototype_: `int omp_get_max_active_levels();'
-
-_Fortran_:
- _Interface_: `int omp_get_max_active_levels()'
-
-_See also_:
- *note omp_set_max_active_levels::, *note omp_get_active_level::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.14.
-
-\1f
-File: libgomp.info, Node: omp_get_max_threads, Next: omp_get_nested, Prev: omp_get_max_active_levels, Up: Runtime Library Routines
-
-2.6 `omp_get_max_threads' - Maximal number of threads of parallel region
-========================================================================
-
-_Description_:
- Return the maximal number of threads used for the current parallel
- region that does not use the clause `num_threads'.
-
-_C/C++_:
- _Prototype_: `int omp_get_max_threads();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_max_threads()'
-
-_See also_:
- *note omp_set_num_threads::, *note omp_set_dynamic::, *note
- omp_get_thread_limit::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.3.
-
-\1f
-File: libgomp.info, Node: omp_get_nested, Next: omp_get_num_procs, Prev: omp_get_max_threads, Up: Runtime Library Routines
-
-2.7 `omp_get_nested' - Nested parallel regions
-==============================================
-
-_Description_:
- This function returns `true' if nested parallel regions are
- enabled, `false' otherwise. Here, `true' and `false' represent
- their language-specific counterparts.
-
- Nested parallel regions may be initialized at startup by the
- `OMP_NESTED' environment variable or at runtime using
- `omp_set_nested'. If undefined, nested parallel regions are
- disabled by default.
-
-_C/C++_:
- _Prototype_: `int omp_get_nested();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_nested()'
-
-_See also_:
- *note omp_set_nested::, *note OMP_NESTED::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.10.
-
-\1f
-File: libgomp.info, Node: omp_get_num_procs, Next: omp_get_num_threads, Prev: omp_get_nested, Up: Runtime Library Routines
-
-2.8 `omp_get_num_procs' - Number of processors online
-=====================================================
-
-_Description_:
- Returns the number of processors online.
-
-_C/C++_:
- _Prototype_: `int omp_get_num_procs();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_num_procs()'
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.5.
-
-\1f
-File: libgomp.info, Node: omp_get_num_threads, Next: omp_get_schedule, Prev: omp_get_num_procs, Up: Runtime Library Routines
-
-2.9 `omp_get_num_threads' - Size of the active team
-===================================================
-
-_Description_:
- The number of threads in the current team. In a sequential section
- of the program `omp_get_num_threads' returns 1.
-
- The default team size may be initialized at startup by the
- `OMP_NUM_THREADS' environment variable. At runtime, the size of
- the current team may be set either by the `NUM_THREADS' clause or
- by `omp_set_num_threads'. If none of the above were used to define
- a specific value and `OMP_DYNAMIC' is disabled, one thread per CPU
- online is used.
-
-_C/C++_:
- _Prototype_: `int omp_get_num_threads();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_num_threads()'
-
-_See also_:
- *note omp_get_max_threads::, *note omp_set_num_threads::, *note
- OMP_NUM_THREADS::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.2.
-
-\1f
-File: libgomp.info, Node: omp_get_schedule, Next: omp_get_team_size, Prev: omp_get_num_threads, Up: Runtime Library Routines
-
-2.10 `omp_get_schedule' - Obtain the runtime scheduling method
-==============================================================
-
-_Description_:
- Obtain runtime the scheduling method. The KIND argument will be
- set to the value `omp_sched_static', `omp_sched_dynamic',
- `opm_sched_guided' or `auto'. The second argument, MODIFIER, is
- set to the chunk size.
-
-_C/C++_
- _Prototype_: `omp_schedule(omp_sched_t * kind, int *modifier);'
-
-_Fortran_:
- _Interface_: `subroutine omp_schedule(kind, modifier)'
- `integer(kind=omp_sched_kind) kind'
- `integer modifier'
-
-_See also_:
- *note omp_set_schedule::, *note OMP_SCHEDULE::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.12.
-
-\1f
-File: libgomp.info, Node: omp_get_team_size, Next: omp_get_thread_limit, Prev: omp_get_schedule, Up: Runtime Library Routines
-
-2.11 `omp_get_team_size' - Number of threads in a team
-======================================================
-
-_Description_:
- This function returns the number of threads in a thread team to
- which either the current thread or its ancestor belongs. For
- values of LEVEL outside zero to `omp_get_level' -1 is returned; if
- LEVEL is zero 1 is returned and for `omp_get_level' the result is
- identical to `omp_get_num_threads'.
-
-_C/C++_:
- _Prototype_: `int omp_get_time_size(int level);'
-
-_Fortran_:
- _Interface_: `integer function omp_get_team_size(level)'
- `integer level'
-
-_See also_:
- *note omp_get_num_threads::, *note omp_get_level::, *note
- omp_get_ancestor_thread_num::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.18.
-
-\1f
-File: libgomp.info, Node: omp_get_thread_limit, Next: omp_get_thread_num, Prev: omp_get_team_size, Up: Runtime Library Routines
-
-2.12 `omp_get_thread_limit' - Maximal number of threads
-=======================================================
-
-_Description_:
- Return the maximal number of threads of the program.
-
-_C/C++_:
- _Prototype_: `int omp_get_thread_limit();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_thread_limit()'
-
-_See also_:
- *note omp_get_max_threads::, *note OMP_THREAD_LIMIT::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.13.
-
-\1f
-File: libgomp.info, Node: omp_get_thread_num, Next: omp_in_parallel, Prev: omp_get_thread_limit, Up: Runtime Library Routines
-
-2.13 `omp_get_thread_num' - Current thread ID
-=============================================
-
-_Description_:
- Unique thread identification number within the current team. In a
- sequential parts of the program, `omp_get_thread_num' always
- returns 0. In parallel regions the return value varies from 0 to
- `omp_get_num_threads'-1 inclusive. The return value of the master
- thread of a team is always 0.
-
-_C/C++_:
- _Prototype_: `int omp_get_thread_num();'
-
-_Fortran_:
- _Interface_: `integer function omp_get_thread_num()'
-
-_See also_:
- *note omp_get_num_threads::, *note omp_get_ancestor_thread_num::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.4.
-
-\1f
-File: libgomp.info, Node: omp_in_parallel, Next: omp_set_dynamic, Prev: omp_get_thread_num, Up: Runtime Library Routines
-
-2.14 `omp_in_parallel' - Whether a parallel region is active
-============================================================
-
-_Description_:
- This function returns `true' if currently running in parallel,
- `false' otherwise. Here, `true' and `false' represent their
- language-specific counterparts.
-
-_C/C++_:
- _Prototype_: `int omp_in_parallel();'
-
-_Fortran_:
- _Interface_: `logical function omp_in_parallel()'
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.6.
-
-\1f
-File: libgomp.info, Node: omp_set_dynamic, Next: omp_set_max_active_levels, Prev: omp_in_parallel, Up: Runtime Library Routines
-
-2.15 `omp_set_dynamic' - Enable/disable dynamic teams
-=====================================================
-
-_Description_:
- Enable or disable the dynamic adjustment of the number of threads
- within a team. The function takes the language-specific equivalent
- of `true' and `false', where `true' enables dynamic adjustment of
- team sizes and `false' disables it.
-
-_C/C++_:
- _Prototype_: `void omp_set_dynamic(int);'
-
-_Fortran_:
- _Interface_: `subroutine omp_set_dynamic(set)'
- `integer, intent(in) :: set'
-
-_See also_:
- *note OMP_DYNAMIC::, *note omp_get_dynamic::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.7.
-
-\1f
-File: libgomp.info, Node: omp_set_max_active_levels, Next: omp_set_nested, Prev: omp_set_dynamic, Up: Runtime Library Routines
-
-2.16 `omp_set_max_active_levels' - Limits the number of active parallel regions
-===============================================================================
-
-_Description_:
- This function limits the maximally allowed number of nested,
- active parallel regions.
-
-_C/C++_
- _Prototype_: `omp_set_max_active_levels(int max_levels);'
-
-_Fortran_:
- _Interface_: `omp_max_active_levels(max_levels)'
- `integer max_levels'
-
-_See also_:
- *note omp_get_max_active_levels::, *note omp_get_active_level::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.14.
-
-\1f
-File: libgomp.info, Node: omp_set_nested, Next: omp_set_num_threads, Prev: omp_set_max_active_levels, Up: Runtime Library Routines
-
-2.17 `omp_set_nested' - Enable/disable nested parallel regions
-==============================================================
-
-_Description_:
- Enable or disable nested parallel regions, i.e., whether team
- members are allowed to create new teams. The function takes the
- language-specific equivalent of `true' and `false', where `true'
- enables dynamic adjustment of team sizes and `false' disables it.
-
-_C/C++_:
- _Prototype_: `void omp_set_dynamic(int);'
-
-_Fortran_:
- _Interface_: `subroutine omp_set_dynamic(set)'
- `integer, intent(in) :: set'
-
-_See also_:
- *note OMP_NESTED::, *note omp_get_nested::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.9.
-
-\1f
-File: libgomp.info, Node: omp_set_num_threads, Next: omp_set_schedule, Prev: omp_set_nested, Up: Runtime Library Routines
-
-2.18 `omp_set_num_threads' - Set upper team size limit
-======================================================
-
-_Description_:
- Specifies the number of threads used by default in subsequent
- parallel sections, if those do not specify a `num_threads' clause.
- The argument of `omp_set_num_threads' shall be a positive integer.
-
-_C/C++_:
- _Prototype_: `void omp_set_num_threads(int);'
-
-_Fortran_:
- _Interface_: `subroutine omp_set_num_threads(set)'
- `integer, intent(in) :: set'
-
-_See also_:
- *note OMP_NUM_THREADS::, *note omp_get_num_threads::, *note
- omp_get_max_threads::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.2.1.
-
-\1f
-File: libgomp.info, Node: omp_set_schedule, Next: omp_init_lock, Prev: omp_set_num_threads, Up: Runtime Library Routines
-
-2.19 `omp_set_schedule' - Set the runtime scheduling method
-===========================================================
-
-_Description_:
- Sets the runtime scheduling method. The KIND argument can have the
- value `omp_sched_static', `omp_sched_dynamic', `opm_sched_guided'
- or `omp_sched_auto'. Except for `omp_sched_auto', the chunk size
- is set to the value of MODIFIER if positive or to the default
- value if zero or negative. For `omp_sched_auto' the MODIFIER
- argument is ignored.
-
-_C/C++_
- _Prototype_: `int omp_schedule(omp_sched_t * kind, int *modifier);'
-
-_Fortran_:
- _Interface_: `subroutine omp_schedule(kind, modifier)'
- `integer(kind=omp_sched_kind) kind'
- `integer modifier'
-
-_See also_:
- *note omp_get_schedule:: *note OMP_SCHEDULE::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section
- 3.2.11.
-
-\1f
-File: libgomp.info, Node: omp_init_lock, Next: omp_set_lock, Prev: omp_set_schedule, Up: Runtime Library Routines
-
-2.20 `omp_init_lock' - Initialize simple lock
-=============================================
-
-_Description_:
- Initialize a simple lock. After initialization, the lock is in an
- unlocked state.
-
-_C/C++_:
- _Prototype_: `void omp_init_lock(omp_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_init_lock(lock)'
- `integer(omp_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_destroy_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.1.
-
-\1f
-File: libgomp.info, Node: omp_set_lock, Next: omp_test_lock, Prev: omp_init_lock, Up: Runtime Library Routines
-
-2.21 `omp_set_lock' - Wait for and set simple lock
-==================================================
-
-_Description_:
- Before setting a simple lock, the lock variable must be
- initialized by `omp_init_lock'. The calling thread is blocked
- until the lock is available. If the lock is already held by the
- current thread, a deadlock occurs.
-
-_C/C++_:
- _Prototype_: `void omp_set_lock(omp_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_set_lock(lock)'
- `integer(omp_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_init_lock::, *note omp_test_lock::, *note
- omp_unset_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.3.
-
-\1f
-File: libgomp.info, Node: omp_test_lock, Next: omp_unset_lock, Prev: omp_set_lock, Up: Runtime Library Routines
-
-2.22 `omp_test_lock' - Test and set simple lock if available
-============================================================
-
-_Description_:
- Before setting a simple lock, the lock variable must be
- initialized by `omp_init_lock'. Contrary to `omp_set_lock',
- `omp_test_lock' does not block if the lock is not available. This
- function returns `true' upon success, `false' otherwise. Here,
- `true' and `false' represent their language-specific counterparts.
-
-_C/C++_:
- _Prototype_: `int omp_test_lock(omp_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_test_lock(lock)'
- `logical(omp_logical_kind) :: omp_test_lock'
- `integer(omp_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.5.
-
-\1f
-File: libgomp.info, Node: omp_unset_lock, Next: omp_destroy_lock, Prev: omp_test_lock, Up: Runtime Library Routines
-
-2.23 `omp_unset_lock' - Unset simple lock
-=========================================
-
-_Description_:
- A simple lock about to be unset must have been locked by
- `omp_set_lock' or `omp_test_lock' before. In addition, the lock
- must be held by the thread calling `omp_unset_lock'. Then, the
- lock becomes unlocked. If one ore more threads attempted to set
- the lock before, one of them is chosen to, again, set the lock for
- itself.
-
-_C/C++_:
- _Prototype_: `void omp_unset_lock(omp_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_unset_lock(lock)'
- `integer(omp_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_set_lock::, *note omp_test_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.4.
-
-\1f
-File: libgomp.info, Node: omp_destroy_lock, Next: omp_init_nest_lock, Prev: omp_unset_lock, Up: Runtime Library Routines
-
-2.24 `omp_destroy_lock' - Destroy simple lock
-=============================================
-
-_Description_:
- Destroy a simple lock. In order to be destroyed, a simple lock
- must be in the unlocked state.
-
-_C/C++_:
- _Prototype_: `void omp_destroy_lock(omp_lock_t *);'
-
-_Fortran_:
- _Interface_: `subroutine omp_destroy_lock(lock)'
- `integer(omp_lock_kind), intent(inout) :: lock'
-
-_See also_:
- *note omp_init_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.2.
-
-\1f
-File: libgomp.info, Node: omp_init_nest_lock, Next: omp_set_nest_lock, Prev: omp_destroy_lock, Up: Runtime Library Routines
-
-2.25 `omp_init_nest_lock' - Initialize nested lock
-==================================================
-
-_Description_:
- Initialize a nested lock. After initialization, the lock is in an
- unlocked state and the nesting count is set to zero.
-
-_C/C++_:
- _Prototype_: `void omp_init_nest_lock(omp_nest_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_init_nest_lock(lock)'
- `integer(omp_nest_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_destroy_nest_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.1.
-
-\1f
-File: libgomp.info, Node: omp_set_nest_lock, Next: omp_test_nest_lock, Prev: omp_init_nest_lock, Up: Runtime Library Routines
-
-2.26 `omp_set_nest_lock' - Wait for and set simple lock
-=======================================================
-
-_Description_:
- Before setting a nested lock, the lock variable must be
- initialized by `omp_init_nest_lock'. The calling thread is blocked
- until the lock is available. If the lock is already held by the
- current thread, the nesting count for the lock in incremented.
-
-_C/C++_:
- _Prototype_: `void omp_set_nest_lock(omp_nest_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_set_nest_lock(lock)'
- `integer(omp_nest_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_init_nest_lock::, *note omp_unset_nest_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.3.
-
-\1f
-File: libgomp.info, Node: omp_test_nest_lock, Next: omp_unset_nest_lock, Prev: omp_set_nest_lock, Up: Runtime Library Routines
-
-2.27 `omp_test_nest_lock' - Test and set nested lock if available
-=================================================================
-
-_Description_:
- Before setting a nested lock, the lock variable must be
- initialized by `omp_init_nest_lock'. Contrary to
- `omp_set_nest_lock', `omp_test_nest_lock' does not block if the
- lock is not available. If the lock is already held by the current
- thread, the new nesting count is returned. Otherwise, the return
- value equals zero.
-
-_C/C++_:
- _Prototype_: `int omp_test_nest_lock(omp_nest_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `integer function omp_test_nest_lock(lock)'
- `integer(omp_integer_kind) :: omp_test_nest_lock'
- `integer(omp_nest_lock_kind), intent(inout) :: lock'
-
-_See also_:
- *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.5.
-
-\1f
-File: libgomp.info, Node: omp_unset_nest_lock, Next: omp_destroy_nest_lock, Prev: omp_test_nest_lock, Up: Runtime Library Routines
-
-2.28 `omp_unset_nest_lock' - Unset nested lock
-==============================================
-
-_Description_:
- A nested lock about to be unset must have been locked by
- `omp_set_nested_lock' or `omp_test_nested_lock' before. In
- addition, the lock must be held by the thread calling
- `omp_unset_nested_lock'. If the nesting count drops to zero, the
- lock becomes unlocked. If one ore more threads attempted to set
- the lock before, one of them is chosen to, again, set the lock for
- itself.
-
-_C/C++_:
- _Prototype_: `void omp_unset_nest_lock(omp_nest_lock_t *lock);'
-
-_Fortran_:
- _Interface_: `subroutine omp_unset_nest_lock(lock)'
- `integer(omp_nest_lock_kind), intent(out) :: lock'
-
-_See also_:
- *note omp_set_nest_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.4.
-
-\1f
-File: libgomp.info, Node: omp_destroy_nest_lock, Next: omp_get_wtick, Prev: omp_unset_nest_lock, Up: Runtime Library Routines
-
-2.29 `omp_destroy_nest_lock' - Destroy nested lock
-==================================================
-
-_Description_:
- Destroy a nested lock. In order to be destroyed, a nested lock
- must be in the unlocked state and its nesting count must equal
- zero.
-
-_C/C++_:
- _Prototype_: `void omp_destroy_nest_lock(omp_nest_lock_t *);'
-
-_Fortran_:
- _Interface_: `subroutine omp_destroy_nest_lock(lock)'
- `integer(omp_nest_lock_kind), intent(inout) :: lock'
-
-_See also_:
- *note omp_init_lock::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.3.2.
-
-\1f
-File: libgomp.info, Node: omp_get_wtick, Next: omp_get_wtime, Prev: omp_destroy_nest_lock, Up: Runtime Library Routines
-
-2.30 `omp_get_wtick' - Get timer precision
-==========================================
-
-_Description_:
- Gets the timer precision, i.e., the number of seconds between two
- successive clock ticks.
-
-_C/C++_:
- _Prototype_: `double omp_get_wtick();'
-
-_Fortran_:
- _Interface_: `double precision function omp_get_wtick()'
-
-_See also_:
- *note omp_get_wtime::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.4.2.
-
-\1f
-File: libgomp.info, Node: omp_get_wtime, Prev: omp_get_wtick, Up: Runtime Library Routines
-
-2.31 `omp_get_wtime' - Elapsed wall clock time
-==============================================
-
-_Description_:
- Elapsed wall clock time in seconds. The time is measured per
- thread, no guarantee can bee made that two distinct threads
- measure the same time. Time is measured from some "time in the
- past". On POSIX compliant systems the seconds since the Epoch
- (00:00:00 UTC, January 1, 1970) are returned.
-
-_C/C++_:
- _Prototype_: `double omp_get_wtime();'
-
-_Fortran_:
- _Interface_: `double precision function omp_get_wtime()'
-
-_See also_:
- *note omp_get_wtick::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 3.4.1.
-
-\1f
-File: libgomp.info, Node: Environment Variables, Next: The libgomp ABI, Prev: Runtime Library Routines, Up: Top
-
-3 Environment Variables
-***********************
-
-The variables `OMP_DYNAMIC', `OMP_MAX_ACTIVE_LEVELS', `OMP_NESTED',
-`OMP_NUM_THREADS', `OMP_SCHEDULE', `OMP_STACKSIZE',`OMP_THREAD_LIMIT'
-and `OMP_WAIT_POLICY' are defined by section 4 of the OpenMP
-specifications in version 3.0, while `GOMP_CPU_AFFINITY' and
-`GOMP_STACKSIZE' are GNU extensions.
-
-* Menu:
-
-* OMP_DYNAMIC:: Dynamic adjustment of threads
-* OMP_MAX_ACTIVE_LEVELS:: Set the maximal number of nested parallel regions
-* OMP_NESTED:: Nested parallel regions
-* OMP_NUM_THREADS:: Specifies the number of threads to use
-* OMP_STACKSIZE:: Set default thread stack size
-* OMP_SCHEDULE:: How threads are scheduled
-* OMP_THREAD_LIMIT:: Set the maximal number of threads
-* OMP_WAIT_POLICY:: How waiting threads are handled
-* GOMP_CPU_AFFINITY:: Bind threads to specific CPUs
-* GOMP_STACKSIZE:: Set default thread stack size
-
-\1f
-File: libgomp.info, Node: OMP_DYNAMIC, Next: OMP_MAX_ACTIVE_LEVELS, Up: Environment Variables
-
-3.1 `OMP_DYNAMIC' - Dynamic adjustment of threads
-=================================================
-
-_Description_:
- Enable or disable the dynamic adjustment of the number of threads
- within a team. The value of this environment variable shall be
- `TRUE' or `FALSE'. If undefined, dynamic adjustment is disabled by
- default.
-
-_See also_:
- *note omp_set_dynamic::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 4.3
-
-\1f
-File: libgomp.info, Node: OMP_MAX_ACTIVE_LEVELS, Next: OMP_NESTED, Prev: OMP_DYNAMIC, Up: Environment Variables
-
-3.2 `OMP_MAX_ACTIVE_LEVELS' - Set the maximal number of nested parallel regions
-===============================================================================
-
-_Description_:
- Specifies the initial value for the maximal number of nested
- parallel regions. The value of this variable shall be positive
- integer. If undefined, the number of active levels is unlimited.
-
-_See also_:
- *note omp_set_max_active_levels::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 4.7
-
-\1f
-File: libgomp.info, Node: OMP_NESTED, Next: OMP_NUM_THREADS, Prev: OMP_MAX_ACTIVE_LEVELS, Up: Environment Variables
-
-3.3 `OMP_NESTED' - Nested parallel regions
-==========================================
-
-_Description_:
- Enable or disable nested parallel regions, i.e., whether team
- members are allowed to create new teams. The value of this
- environment variable shall be `TRUE' or `FALSE'. If undefined,
- nested parallel regions are disabled by default.
-
-_See also_:
- *note omp_set_nested::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 4.4
-
-\1f
-File: libgomp.info, Node: OMP_NUM_THREADS, Next: OMP_STACKSIZE, Prev: OMP_NESTED, Up: Environment Variables
-
-3.4 `OMP_NUM_THREADS' - Specifies the number of threads to use
-==============================================================
-
-_Description_:
- Specifies the default number of threads to use in parallel
- regions. The value of this variable shall be positive integer. If
- undefined one thread per CPU online is used.
-
-_See also_:
- *note omp_set_num_threads::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 4.2
-
-\1f
-File: libgomp.info, Node: OMP_SCHEDULE, Next: OMP_THREAD_LIMIT, Prev: OMP_STACKSIZE, Up: Environment Variables
-
-3.5 `OMP_SCHEDULE' - How threads are scheduled
-==============================================
-
-_Description_:
- Allows to specify `schedule type' and `chunk size'. The value of
- the variable shall have the form: `type[,chunk]' where `type' is
- one of `static', `dynamic', `guided' or `auto' The optional
- `chunk' size shall be a positive integer. If undefined, dynamic
- scheduling and a chunk size of 1 is used.
-
-_See also_:
- *note omp_set_schedule::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), sections
- 2.5.1 and 4.1
-
-\1f
-File: libgomp.info, Node: OMP_STACKSIZE, Next: OMP_SCHEDULE, Prev: OMP_NUM_THREADS, Up: Environment Variables
-
-3.6 `OMP_STACKSIZE' - Set default thread stack size
-===================================================
-
-_Description_:
- Set the default thread stack size in kilobytes, unless the number
- is suffixed by `B', `K', `M' or `G', in which case the size is,
- respectively, in bytes, kilobytes, megabytes or gigabytes. This is
- different from `pthread_attr_setstacksize' which gets the number
- of bytes as an argument. If the stacksize can not be set due to
- system constraints, an error is reported and the initial stacksize
- is left unchanged. If undefined, the stack size is system
- dependent.
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), sections 4.5
-
-\1f
-File: libgomp.info, Node: OMP_THREAD_LIMIT, Next: OMP_WAIT_POLICY, Prev: OMP_SCHEDULE, Up: Environment Variables
-
-3.7 `OMP_THREAD_LIMIT' - Set the maximal number of threads
-==========================================================
-
-_Description_:
- Specifies the number of threads to use for the whole program. The
- value of this variable shall be positive integer. If undefined,
- the number of threads is not limited.
-
-_See also_:
- *note OMP_NUM_THREADS:: *note omp_get_thread_limit::
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), section 4.8
-
-\1f
-File: libgomp.info, Node: OMP_WAIT_POLICY, Next: GOMP_CPU_AFFINITY, Prev: OMP_THREAD_LIMIT, Up: Environment Variables
-
-3.8 `OMP_WAIT_POLICY' - How waiting threads are handled
-=======================================================
-
-_Description_:
- Specifies whether waiting threads should be active or passive. If
- the value is `PASSIVE', waiting threads should not consume CPU
- power while waiting; while the value is `ACTIVE' specifies that
- they should.
-
-_Reference_:
- OpenMP specifications v3.0 (http://www.openmp.org/), sections 4.6
-
-\1f
-File: libgomp.info, Node: GOMP_CPU_AFFINITY, Next: GOMP_STACKSIZE, Prev: OMP_WAIT_POLICY, Up: Environment Variables
-
-3.9 `GOMP_CPU_AFFINITY' - Bind threads to specific CPUs
-=======================================================
-
-_Description_:
- Binds threads to specific CPUs. The variable should contain a
- space- or comma-separated list of CPUs. This list may contain
- different kind of entries: either single CPU numbers in any order,
- a range of CPUs (M-N) or a range with some stride (M-N:S). CPU
- numbers are zero based. For example, `GOMP_CPU_AFFINITY="0 3 1-2
- 4-15:2"' will bind the initial thread to CPU 0, the second to CPU
- 3, the third to CPU 1, the fourth to CPU 2, the fifth to CPU 4,
- the sixth through tenth to CPUs 6, 8, 10, 12, and 14 respectively
- and then start assigning back from the beginning of the list.
- `GOMP_CPU_AFFINITY=0' binds all threads to CPU 0.
-
- There is no GNU OpenMP library routine to determine whether a CPU
- affinity specification is in effect. As a workaround,
- language-specific library functions, e.g., `getenv' in C or
- `GET_ENVIRONMENT_VARIABLE' in Fortran, may be used to query the
- setting of the `GOMP_CPU_AFFINITY' environment variable. A defined
- CPU affinity on startup cannot be changed or disabled during the
- runtime of the application.
-
- If this environment variable is omitted, the host system will
- handle the assignment of threads to CPUs.
-
-\1f
-File: libgomp.info, Node: GOMP_STACKSIZE, Prev: GOMP_CPU_AFFINITY, Up: Environment Variables
-
-3.10 `GOMP_STACKSIZE' - Set default thread stack size
-=====================================================
-
-_Description_:
- Set the default thread stack size in kilobytes. This is different
- from `pthread_attr_setstacksize' which gets the number of bytes as
- an argument. If the stacksize can not be set due to system
- constraints, an error is reported and the initial stacksize is
- left unchanged. If undefined, the stack size is system dependent.
-
-_See also_:
- *note GOMP_STACKSIZE::
-
-_Reference_:
- GCC Patches Mailinglist
- (http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00493.html), GCC
- Patches Mailinglist
- (http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00496.html)
-
-\1f
-File: libgomp.info, Node: The libgomp ABI, Next: Reporting Bugs, Prev: Environment Variables, Up: Top
-
-4 The libgomp ABI
-*****************
-
-The following sections present notes on the external ABI as presented
-by libgomp. Only maintainers should need them.
-
-* Menu:
-
-* Implementing MASTER construct::
-* Implementing CRITICAL construct::
-* Implementing ATOMIC construct::
-* Implementing FLUSH construct::
-* Implementing BARRIER construct::
-* Implementing THREADPRIVATE construct::
-* Implementing PRIVATE clause::
-* Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses::
-* Implementing REDUCTION clause::
-* Implementing PARALLEL construct::
-* Implementing FOR construct::
-* Implementing ORDERED construct::
-* Implementing SECTIONS construct::
-* Implementing SINGLE construct::
-
-\1f
-File: libgomp.info, Node: Implementing MASTER construct, Next: Implementing CRITICAL construct, Up: The libgomp ABI
-
-4.1 Implementing MASTER construct
-=================================
-
- if (omp_get_thread_num () == 0)
- block
-
- Alternately, we generate two copies of the parallel subfunction and
-only include this in the version run by the master thread. Surely
-that's not worthwhile though...
-
-\1f
-File: libgomp.info, Node: Implementing CRITICAL construct, Next: Implementing ATOMIC construct, Prev: Implementing MASTER construct, Up: The libgomp ABI
-
-4.2 Implementing CRITICAL construct
-===================================
-
-Without a specified name,
-
- void GOMP_critical_start (void);
- void GOMP_critical_end (void);
-
- so that we don't get COPY relocations from libgomp to the main
-application.
-
- With a specified name, use omp_set_lock and omp_unset_lock with name
-being transformed into a variable declared like
-
- omp_lock_t gomp_critical_user_<name> __attribute__((common))
-
- Ideally the ABI would specify that all zero is a valid unlocked
-state, and so we wouldn't actually need to initialize this at startup.
-
-\1f
-File: libgomp.info, Node: Implementing ATOMIC construct, Next: Implementing FLUSH construct, Prev: Implementing CRITICAL construct, Up: The libgomp ABI
-
-4.3 Implementing ATOMIC construct
-=================================
-
-The target should implement the `__sync' builtins.
-
- Failing that we could add
-
- void GOMP_atomic_enter (void)
- void GOMP_atomic_exit (void)
-
- which reuses the regular lock code, but with yet another lock object
-private to the library.
-
-\1f
-File: libgomp.info, Node: Implementing FLUSH construct, Next: Implementing BARRIER construct, Prev: Implementing ATOMIC construct, Up: The libgomp ABI
-
-4.4 Implementing FLUSH construct
-================================
-
-Expands to the `__sync_synchronize' builtin.
-
-\1f
-File: libgomp.info, Node: Implementing BARRIER construct, Next: Implementing THREADPRIVATE construct, Prev: Implementing FLUSH construct, Up: The libgomp ABI
-
-4.5 Implementing BARRIER construct
-==================================
-
- void GOMP_barrier (void)
-
-\1f
-File: libgomp.info, Node: Implementing THREADPRIVATE construct, Next: Implementing PRIVATE clause, Prev: Implementing BARRIER construct, Up: The libgomp ABI
-
-4.6 Implementing THREADPRIVATE construct
-========================================
-
-In _most_ cases we can map this directly to `__thread'. Except that
-OMP allows constructors for C++ objects. We can either refuse to
-support this (how often is it used?) or we can implement something akin
-to .ctors.
-
- Even more ideally, this ctor feature is handled by extensions to the
-main pthreads library. Failing that, we can have a set of entry points
-to register ctor functions to be called.
-
-\1f
-File: libgomp.info, Node: Implementing PRIVATE clause, Next: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses, Prev: Implementing THREADPRIVATE construct, Up: The libgomp ABI
-
-4.7 Implementing PRIVATE clause
-===============================
-
-In association with a PARALLEL, or within the lexical extent of a
-PARALLEL block, the variable becomes a local variable in the parallel
-subfunction.
-
- In association with FOR or SECTIONS blocks, create a new automatic
-variable within the current function. This preserves the semantic of
-new variable creation.
-
-\1f
-File: libgomp.info, Node: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses, Next: Implementing REDUCTION clause, Prev: Implementing PRIVATE clause, Up: The libgomp ABI
-
-4.8 Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses
-========================================================================
-
-Seems simple enough for PARALLEL blocks. Create a private struct for
-communicating between parent and subfunction. In the parent, copy in
-values for scalar and "small" structs; copy in addresses for others
-TREE_ADDRESSABLE types. In the subfunction, copy the value into the
-local variable.
-
- Not clear at all what to do with bare FOR or SECTION blocks. The
-only thing I can figure is that we do something like
-
- #pragma omp for firstprivate(x) lastprivate(y)
- for (int i = 0; i < n; ++i)
- body;
-
- which becomes
-
- {
- int x = x, y;
-
- // for stuff
-
- if (i == n)
- y = y;
- }
-
- where the "x=x" and "y=y" assignments actually have different uids
-for the two variables, i.e. not something you could write directly in
-C. Presumably this only makes sense if the "outer" x and y are global
-variables.
-
- COPYPRIVATE would work the same way, except the structure broadcast
-would have to happen via SINGLE machinery instead.
-
-\1f
-File: libgomp.info, Node: Implementing REDUCTION clause, Next: Implementing PARALLEL construct, Prev: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses, Up: The libgomp ABI
-
-4.9 Implementing REDUCTION clause
-=================================
-
-The private struct mentioned in the previous section should have a
-pointer to an array of the type of the variable, indexed by the
-thread's TEAM_ID. The thread stores its final value into the array,
-and after the barrier the master thread iterates over the array to
-collect the values.
-
-\1f
-File: libgomp.info, Node: Implementing PARALLEL construct, Next: Implementing FOR construct, Prev: Implementing REDUCTION clause, Up: The libgomp ABI
-
-4.10 Implementing PARALLEL construct
-====================================
-
- #pragma omp parallel
- {
- body;
- }
-
- becomes
-
- void subfunction (void *data)
- {
- use data;
- body;
- }
-
- setup data;
- GOMP_parallel_start (subfunction, &data, num_threads);
- subfunction (&data);
- GOMP_parallel_end ();
-
- void GOMP_parallel_start (void (*fn)(void *), void *data, unsigned num_threads)
-
- The FN argument is the subfunction to be run in parallel.
-
- The DATA argument is a pointer to a structure used to communicate
-data in and out of the subfunction, as discussed above with respect to
-FIRSTPRIVATE et al.
-
- The NUM_THREADS argument is 1 if an IF clause is present and false,
-or the value of the NUM_THREADS clause, if present, or 0.
-
- The function needs to create the appropriate number of threads
-and/or launch them from the dock. It needs to create the team
-structure and assign team ids.
-
- void GOMP_parallel_end (void)
-
- Tears down the team and returns us to the previous
-`omp_in_parallel()' state.
-
-\1f
-File: libgomp.info, Node: Implementing FOR construct, Next: Implementing ORDERED construct, Prev: Implementing PARALLEL construct, Up: The libgomp ABI
-
-4.11 Implementing FOR construct
-===============================
-
- #pragma omp parallel for
- for (i = lb; i <= ub; i++)
- body;
-
- becomes
-
- void subfunction (void *data)
- {
- long _s0, _e0;
- while (GOMP_loop_static_next (&_s0, &_e0))
- {
- long _e1 = _e0, i;
- for (i = _s0; i < _e1; i++)
- body;
- }
- GOMP_loop_end_nowait ();
- }
-
- GOMP_parallel_loop_static (subfunction, NULL, 0, lb, ub+1, 1, 0);
- subfunction (NULL);
- GOMP_parallel_end ();
-
- #pragma omp for schedule(runtime)
- for (i = 0; i < n; i++)
- body;
-
- becomes
-
- {
- long i, _s0, _e0;
- if (GOMP_loop_runtime_start (0, n, 1, &_s0, &_e0))
- do {
- long _e1 = _e0;
- for (i = _s0, i < _e0; i++)
- body;
- } while (GOMP_loop_runtime_next (&_s0, _&e0));
- GOMP_loop_end ();
- }
-
- Note that while it looks like there is trickyness to propagating a
-non-constant STEP, there isn't really. We're explicitly allowed to
-evaluate it as many times as we want, and any variables involved should
-automatically be handled as PRIVATE or SHARED like any other variables.
-So the expression should remain evaluable in the subfunction. We can
-also pull it into a local variable if we like, but since its supposed
-to remain unchanged, we can also not if we like.
-
- If we have SCHEDULE(STATIC), and no ORDERED, then we ought to be
-able to get away with no work-sharing context at all, since we can
-simply perform the arithmetic directly in each thread to divide up the
-iterations. Which would mean that we wouldn't need to call any of
-these routines.
-
- There are separate routines for handling loops with an ORDERED
-clause. Bookkeeping for that is non-trivial...
-
-\1f
-File: libgomp.info, Node: Implementing ORDERED construct, Next: Implementing SECTIONS construct, Prev: Implementing FOR construct, Up: The libgomp ABI
-
-4.12 Implementing ORDERED construct
-===================================
-
- void GOMP_ordered_start (void)
- void GOMP_ordered_end (void)
-
-\1f
-File: libgomp.info, Node: Implementing SECTIONS construct, Next: Implementing SINGLE construct, Prev: Implementing ORDERED construct, Up: The libgomp ABI
-
-4.13 Implementing SECTIONS construct
-====================================
-
-A block as
-
- #pragma omp sections
- {
- #pragma omp section
- stmt1;
- #pragma omp section
- stmt2;
- #pragma omp section
- stmt3;
- }
-
- becomes
-
- for (i = GOMP_sections_start (3); i != 0; i = GOMP_sections_next ())
- switch (i)
- {
- case 1:
- stmt1;
- break;
- case 2:
- stmt2;
- break;
- case 3:
- stmt3;
- break;
- }
- GOMP_barrier ();
-
-\1f
-File: libgomp.info, Node: Implementing SINGLE construct, Prev: Implementing SECTIONS construct, Up: The libgomp ABI
-
-4.14 Implementing SINGLE construct
-==================================
-
-A block like
-
- #pragma omp single
- {
- body;
- }
-
- becomes
-
- if (GOMP_single_start ())
- body;
- GOMP_barrier ();
-
- while
-
- #pragma omp single copyprivate(x)
- body;
-
- becomes
-
- datap = GOMP_single_copy_start ();
- if (datap == NULL)
- {
- body;
- data.x = x;
- GOMP_single_copy_end (&data);
- }
- else
- x = datap->x;
- GOMP_barrier ();
-
-\1f
-File: libgomp.info, Node: Reporting Bugs, Next: Copying, Prev: The libgomp ABI, Up: Top
-
-5 Reporting Bugs
-****************
-
-Bugs in the GNU OpenMP implementation should be reported via bugzilla
-(http://gcc.gnu.org/bugzilla/). In all cases, please add "openmp" to
-the keywords field in the bug report.
-
-\1f
-File: libgomp.info, Node: Copying, Next: GNU Free Documentation License, Prev: Reporting Bugs, Up: Top
-
-GNU GENERAL PUBLIC LICENSE
-**************************
-
- Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-Preamble
-========
-
-The licenses for most software are designed to take away your freedom
-to share and change it. By contrast, the GNU General Public License is
-intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users. This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it. (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.) 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
-this service 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 make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have. 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.
-
- We protect your rights with two steps: (1) copyright the software,
-and (2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
- Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software. If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
- Finally, any free program is threatened constantly by software
-patents. We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary. To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
- 0. This License applies to any program or other work which contains a
- notice placed by the copyright holder saying it may be distributed
- under the terms of this General Public License. The "Program",
- below, refers to any such program or work, and a "work based on
- the Program" means either the Program or any derivative work under
- copyright law: that is to say, a work containing the Program or a
- portion of it, either verbatim or with modifications and/or
- translated into another language. (Hereinafter, translation is
- included without limitation in the term "modification".) Each
- licensee is addressed as "you".
-
- Activities other than copying, distribution and modification are
- not covered by this License; they are outside its scope. The act
- of running the Program is not restricted, and the output from the
- Program is covered only if its contents constitute a work based on
- the Program (independent of having been made by running the
- Program). Whether that is true depends on what the Program does.
-
- 1. You may copy and distribute 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 and disclaimer of warranty; keep intact all the
- notices that refer to this License and to the absence of any
- warranty; and give any other recipients of the Program a copy of
- this License along with the Program.
-
- You may charge a fee for the physical act of transferring a copy,
- and you may at your option offer warranty protection in exchange
- for a fee.
-
- 2. You may modify your copy or copies of the Program or any portion
- of it, thus forming a work based on the Program, and copy and
- distribute such modifications or work under the terms of Section 1
- above, provided that you also meet all of these conditions:
-
- a. You must cause the modified files to carry prominent notices
- stating that you changed the files and the date of any change.
-
- b. You must cause any work that you distribute or publish, that
- in whole or in part contains or is derived from the Program
- or any part thereof, to be licensed as a whole at no charge
- to all third parties under the terms of this License.
-
- c. If the modified program normally reads commands interactively
- when run, you must cause it, when started running for such
- interactive use in the most ordinary way, to print or display
- an announcement including an appropriate copyright notice and
- a notice that there is no warranty (or else, saying that you
- provide a warranty) and that users may redistribute the
- program under these conditions, and telling the user how to
- view a copy of this License. (Exception: if the Program
- itself is interactive but does not normally print such an
- announcement, your work based on the Program is not required
- to print an announcement.)
-
- These requirements apply to the modified work as a whole. If
- identifiable sections of that work are not derived from the
- Program, and can be reasonably considered independent and separate
- works in themselves, then this License, and its terms, do not
- apply to those sections when you distribute them as separate
- works. But when you distribute the same sections as part of a
- whole which is a work based on the Program, the distribution of
- the whole must be on the terms of this License, whose permissions
- for other licensees extend to the entire whole, and thus to each
- and every part regardless of who wrote it.
-
- Thus, it is not the intent of this section to claim rights or
- contest your rights to work written entirely by you; rather, the
- intent is to exercise the right to control the distribution of
- derivative or collective works based on the Program.
-
- In addition, mere aggregation of another work not based on the
- Program with the Program (or with a work based on the Program) on
- a volume of a storage or distribution medium does not bring the
- other work under the scope of this License.
-
- 3. You may copy and distribute the Program (or a work based on it,
- under Section 2) in object code or executable form under the terms
- of Sections 1 and 2 above provided that you also do one of the
- following:
-
- a. Accompany it with the complete corresponding machine-readable
- source code, which must be distributed under the terms of
- Sections 1 and 2 above on a medium customarily used for
- software interchange; or,
-
- b. Accompany it with a written offer, valid for at least three
- years, to give any third party, for a charge no more than your
- cost of physically performing source distribution, a complete
- machine-readable copy of the corresponding source code, to be
- distributed under the terms of Sections 1 and 2 above on a
- medium customarily used for software interchange; or,
-
- c. Accompany it with the information you received as to the offer
- to distribute corresponding source code. (This alternative is
- allowed only for noncommercial distribution and only if you
- received the program in object code or executable form with
- such an offer, in accord with Subsection b above.)
-
- The source code for a work means the preferred form of the work for
- making modifications to it. For an executable work, complete
- source code means all the source code for all modules it contains,
- plus any associated interface definition files, plus the scripts
- used to control compilation and installation of the executable.
- However, as a special exception, the source code distributed need
- not include anything that is normally distributed (in either
- source or binary form) with the major components (compiler,
- kernel, and so on) of the operating system on which the executable
- runs, unless that component itself accompanies the executable.
-
- If distribution of executable or object code is made by offering
- access to copy from a designated place, then offering equivalent
- access to copy the source code from the same place counts as
- distribution of the source code, even though third parties are not
- compelled to copy the source along with the object code.
-
- 4. You may not copy, modify, sublicense, or distribute the Program
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense or distribute the Program is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 5. You are not required to accept this License, since you have not
- signed it. However, nothing else grants you permission to modify
- or distribute the Program or its derivative works. These actions
- are prohibited by law if you do not accept this License.
- Therefore, by modifying or distributing the Program (or any work
- based on the Program), you indicate your acceptance of this
- License to do so, and all its terms and conditions for copying,
- distributing or modifying the Program or works based on it.
-
- 6. Each time you redistribute the Program (or any work based on the
- Program), the recipient automatically receives a license from the
- original licensor to copy, distribute or modify the Program
- subject to these terms and conditions. You may not impose any
- further restrictions on the recipients' exercise of the rights
- granted herein. You are not responsible for enforcing compliance
- by third parties to this License.
-
- 7. If, as a consequence of a court judgment or allegation of patent
- infringement or for any other reason (not limited to patent
- issues), 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 distribute so as to satisfy simultaneously
- your obligations under this License and any other pertinent
- obligations, then as a consequence you may not distribute the
- Program at all. For example, if a patent license would not permit
- royalty-free redistribution of the Program by all those who
- receive copies directly or indirectly through you, then the only
- way you could satisfy both it and this License would be to refrain
- entirely from distribution of the Program.
-
- If any portion of this section is held invalid or unenforceable
- under any particular circumstance, the balance of the section is
- intended to apply and the section as a whole is intended to apply
- in other circumstances.
-
- It is not the purpose of this section to induce you to infringe any
- patents or other property right claims or to contest validity of
- any such claims; this section has the sole purpose of protecting
- the integrity of the free software distribution system, which is
- implemented by public license practices. Many people have made
- generous contributions to the wide range of software distributed
- through that system in reliance on consistent application of that
- system; it is up to the author/donor to decide if he or she is
- willing to distribute software through any other system and a
- licensee cannot impose that choice.
-
- This section is intended to make thoroughly clear what is believed
- to be a consequence of the rest of this License.
-
- 8. If the distribution and/or use of the Program is restricted in
- certain countries either by patents or by copyrighted interfaces,
- the original copyright holder who places the Program under this
- License may add an explicit geographical distribution limitation
- excluding those countries, so that distribution is permitted only
- in or among countries not thus excluded. In such case, this
- License incorporates the limitation as if written in the body of
- this License.
-
- 9. The Free Software Foundation may publish revised and/or new
- versions of the 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 a version number of this License which applies
- to it and "any later version", you have the option of following
- the terms and conditions either of that version or of any later
- version published by the Free Software Foundation. If the Program
- does not specify a version number of this License, you may choose
- any version ever published by the Free Software Foundation.
-
- 10. If you wish to incorporate parts of the Program into other free
- programs whose distribution conditions are different, write to the
- author to ask for permission. For software which is copyrighted
- by the Free Software Foundation, write to the Free Software
- Foundation; we sometimes make exceptions for this. Our decision
- will be guided by the two goals of preserving the free status of
- all derivatives of our free software and of promoting the sharing
- and reuse of software generally.
-
- NO WARRANTY
- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, 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.
-
- 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
- WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
- MODIFY AND/OR REDISTRIBUTE 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.
-
- END OF TERMS AND CONDITIONS
-Appendix: 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
-convey 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 2 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, write to the Free Software
- Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- Also add information on how to contact you by electronic and paper
-mail.
-
- If the program is interactive, make it output a short notice like
-this when it starts in an interactive mode:
-
- Gnomovision version 69, Copyright (C) YEAR NAME OF AUTHOR
- Gnomovision 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, the
-commands you use may be called something other than `show w' and `show
-c'; they could even be mouse-clicks or menu items--whatever suits your
-program.
-
- You should also get your employer (if you work as a programmer) or
-your school, if any, to sign a "copyright disclaimer" for the program,
-if necessary. Here is a sample; alter the names:
-
- Yoyodyne, Inc., hereby disclaims all copyright interest in the program
- `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
- SIGNATURE OF TY COON, 1 April 1989
- Ty Coon, President of Vice
-
- This 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 Library General Public License instead of this License.
-
-\1f
-File: libgomp.info, Node: GNU Free Documentation License, Next: Funding, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-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.2
- 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.
-
-\1f
-File: libgomp.info, Node: Funding, Next: Index, Prev: GNU Free Documentation License, 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.
-
-\1f
-File: libgomp.info, Node: Index, Prev: Funding, Up: Top
-
-Index
-*****
-
-\0\b[index\0\b]
-* Menu:
-
-* Environment Variable <1>: GOMP_STACKSIZE. (line 6)
-* Environment Variable <2>: GOMP_CPU_AFFINITY. (line 6)
-* Environment Variable <3>: OMP_WAIT_POLICY. (line 6)
-* Environment Variable <4>: OMP_THREAD_LIMIT. (line 6)
-* Environment Variable <5>: OMP_STACKSIZE. (line 6)
-* Environment Variable <6>: OMP_SCHEDULE. (line 6)
-* Environment Variable <7>: OMP_NUM_THREADS. (line 6)
-* Environment Variable <8>: OMP_NESTED. (line 6)
-* Environment Variable <9>: OMP_MAX_ACTIVE_LEVELS. (line 6)
-* Environment Variable: OMP_DYNAMIC. (line 6)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* Implementation specific setting <1>: GOMP_STACKSIZE. (line 6)
-* Implementation specific setting <2>: OMP_SCHEDULE. (line 6)
-* Implementation specific setting <3>: OMP_NUM_THREADS. (line 6)
-* Implementation specific setting: OMP_NESTED. (line 6)
-* Introduction: Top. (line 6)
-
-
-\1f
-Tag Table:
-Node: Top\7f2039
-Node: Enabling OpenMP\7f3233
-Node: Runtime Library Routines\7f4018
-Node: omp_get_active_level\7f6393
-Node: omp_get_ancestor_thread_num\7f7084
-Node: omp_get_dynamic\7f7998
-Node: omp_get_level\7f8872
-Node: omp_get_max_active_levels\7f9483
-Node: omp_get_max_threads\7f10171
-Node: omp_get_nested\7f10923
-Node: omp_get_num_procs\7f11831
-Node: omp_get_num_threads\7f12345
-Node: omp_get_schedule\7f13415
-Node: omp_get_team_size\7f14322
-Node: omp_get_thread_limit\7f15280
-Node: omp_get_thread_num\7f15899
-Node: omp_in_parallel\7f16753
-Node: omp_set_dynamic\7f17399
-Node: omp_set_max_active_levels\7f18235
-Node: omp_set_nested\7f18997
-Node: omp_set_num_threads\7f19874
-Node: omp_set_schedule\7f20712
-Node: omp_init_lock\7f21756
-Node: omp_set_lock\7f22406
-Node: omp_test_lock\7f23255
-Node: omp_unset_lock\7f24282
-Node: omp_destroy_lock\7f25208
-Node: omp_init_nest_lock\7f25878
-Node: omp_set_nest_lock\7f26610
-Node: omp_test_nest_lock\7f27519
-Node: omp_unset_nest_lock\7f28617
-Node: omp_destroy_nest_lock\7f29626
-Node: omp_get_wtick\7f30374
-Node: omp_get_wtime\7f30961
-Node: Environment Variables\7f31744
-Node: OMP_DYNAMIC\7f32805
-Node: OMP_MAX_ACTIVE_LEVELS\7f33373
-Node: OMP_NESTED\7f34010
-Node: OMP_NUM_THREADS\7f34614
-Node: OMP_SCHEDULE\7f35187
-Node: OMP_STACKSIZE\7f35881
-Node: OMP_THREAD_LIMIT\7f36706
-Node: OMP_WAIT_POLICY\7f37299
-Node: GOMP_CPU_AFFINITY\7f37864
-Node: GOMP_STACKSIZE\7f39348
-Node: The libgomp ABI\7f40158
-Node: Implementing MASTER construct\7f40956
-Node: Implementing CRITICAL construct\7f41369
-Node: Implementing ATOMIC construct\7f42117
-Node: Implementing FLUSH construct\7f42598
-Node: Implementing BARRIER construct\7f42869
-Node: Implementing THREADPRIVATE construct\7f43138
-Node: Implementing PRIVATE clause\7f43790
-Node: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses\7f44371
-Node: Implementing REDUCTION clause\7f45686
-Node: Implementing PARALLEL construct\7f46242
-Node: Implementing FOR construct\7f47499
-Node: Implementing ORDERED construct\7f49497
-Node: Implementing SECTIONS construct\7f49803
-Node: Implementing SINGLE construct\7f50569
-Node: Reporting Bugs\7f51231
-Node: Copying\7f51539
-Node: GNU Free Documentation License\7f70749
-Node: Funding\7f93160
-Node: Index\7f95677
-\1f
-End Tag Table
+++ /dev/null
-This is ../mpfr.info, produced by makeinfo version 4.12 from
-../mpfr.texi.
-
-This manual documents how to install and use the Multiple Precision
-Floating-Point Reliable Library, version 2.4.1.
-
- Copyright 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.2 or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in *note GNU Free
-Documentation License::.
-
-INFO-DIR-SECTION Software libraries
-START-INFO-DIR-ENTRY
-* mpfr: (mpfr). Multiple Precision Floating-Point Reliable Library.
-END-INFO-DIR-ENTRY
-
-\1f
-File: mpfr.info, Node: Top, Next: Copying, Prev: (dir), Up: (dir)
-
-GNU MPFR
-********
-
- This manual documents how to install and use the Multiple Precision
-Floating-Point Reliable Library, version 2.4.1.
-
- Copyright 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.2 or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in *note GNU Free
-Documentation License::.
-
-
-* Menu:
-
-* Copying:: MPFR Copying Conditions (LGPL).
-* Introduction to MPFR:: Brief introduction to GNU MPFR.
-* Installing MPFR:: How to configure and compile the MPFR library.
-* Reporting Bugs:: How to usefully report bugs.
-* MPFR Basics:: What every MPFR user should now.
-* MPFR Interface:: MPFR functions and macros.
-* Contributors::
-* References::
-* GNU Free Documentation License::
-* Concept Index::
-* Function Index::
-
-\1f
-File: mpfr.info, Node: Copying, Next: Introduction to MPFR, Prev: Top, Up: Top
-
-MPFR Copying Conditions
-***********************
-
-This library is "free"; this means that everyone is free to use it and
-free to redistribute it on a free basis. The library is not in the
-public domain; it is copyrighted and there are restrictions on its
-distribution, but these restrictions are designed to permit everything
-that a good cooperating citizen would want to do. What is not allowed
-is to try to prevent others from further sharing any version of this
-library that they might get from you.
-
- Specifically, we want to make sure that you have the right to give
-away copies of the library, that you receive source code or else can
-get it if you want it, that you can change this library or use pieces
-of it in new free programs, and that you know you can do these things.
-
- To make sure that everyone has such rights, we have to forbid you to
-deprive anyone else of these rights. For example, if you distribute
-copies of the GNU MPFR library, you must give the recipients all the
-rights that you have. You must make sure that they, too, receive or
-can get the source code. And you must tell them their rights.
-
- Also, for our own protection, we must make certain that everyone
-finds out that there is no warranty for the GNU MPFR library. If it is
-modified by someone else and passed on, we want their recipients to
-know that what they have is not what we distributed, so that any
-problems introduced by others will not reflect on our reputation.
-
- The precise conditions of the license for the GNU MPFR library are
-found in the Lesser General Public License that accompanies the source
-code. See the file COPYING.LIB.
-
-\1f
-File: mpfr.info, Node: Introduction to MPFR, Next: Installing MPFR, Prev: Copying, Up: Top
-
-1 Introduction to MPFR
-**********************
-
-MPFR is a portable library written in C for arbitrary precision
-arithmetic on floating-point numbers. It is based on the GNU MP library.
-It aims to extend the class of floating-point numbers provided by the
-GNU MP library by a precise semantics. The main differences with the
-`mpf' class from GNU MP are:
-
- * the MPFR code is portable, i.e. the result of any operation does
- not depend (or should not) on the machine word size
- `mp_bits_per_limb' (32 or 64 on most machines);
-
- * the precision in bits can be set exactly to any valid value for
- each variable (including very small precision);
-
- * MPFR provides the four rounding modes from the IEEE 754-1985
- standard.
-
- In particular, with a precision of 53 bits, MPFR should be able to
-exactly reproduce all computations with double-precision machine
-floating-point numbers (e.g., `double' type in C, with a C
-implementation that rigorously follows Annex F of the ISO C99 standard
-and `FP_CONTRACT' pragma set to `OFF') on the four arithmetic
-operations and the square root, except the default exponent range is
-much wider and subnormal numbers are not implemented (but can be
-emulated).
-
- This version of MPFR is released under the GNU Lesser General Public
-License, Version 2.1 or any later version. It is permitted to link
-MPFR to most non-free programs, as long as when distributing them the
-MPFR source code and a means to re-link with a modified MPFR library is
-provided.
-
-1.1 How to Use This Manual
-==========================
-
-Everyone should read *note MPFR Basics::. If you need to install the
-library yourself, you need to read *note Installing MPFR::, too.
-
- The rest of the manual can be used for later reference, although it
-is probably a good idea to glance through it.
-
-\1f
-File: mpfr.info, Node: Installing MPFR, Next: Reporting Bugs, Prev: Introduction to MPFR, Up: Top
-
-2 Installing MPFR
-*****************
-
-2.1 How to Install
-==================
-
-Here are the steps needed to install the library on Unix systems (more
-details are provided in the `INSTALL' file):
-
- 1. To build MPFR, you first have to install GNU MP (version 4.1 or
- higher) on your computer. You need a C compiler, preferably GCC,
- but any reasonable compiler should work. And you need a standard
- Unix `make' program, plus some other standard Unix utility
- programs.
-
- 2. In the MPFR build directory, type `./configure'
-
- This will prepare the build and setup the options according to
- your system. If you get error messages, you might check that you
- use the same compiler and compile options as for GNU MP (see the
- `INSTALL' file).
-
- 3. `make'
-
- This will compile MPFR, and create a library archive file
- `libmpfr.a'. A dynamic library may be produced too (see
- configure).
-
- 4. `make check'
-
- This will make sure MPFR was built correctly. If you get error
- messages, please report this to `mpfr@loria.fr'. (*Note Reporting
- Bugs::, for information on what to include in useful bug reports.)
-
- 5. `make install'
-
- This will copy the files `mpfr.h' and `mpf2mpfr.h' to the directory
- `/usr/local/include', the file `libmpfr.a' to the directory
- `/usr/local/lib', and the file `mpfr.info' to the directory
- `/usr/local/share/info' (or if you passed the `--prefix' option to
- `configure', using the prefix directory given as argument to
- `--prefix' instead of `/usr/local').
-
-2.2 Other `make' Targets
-========================
-
-There are some other useful make targets:
-
- * `mpfr.info' or `info'
-
- Create an info version of the manual, in `mpfr.info'.
-
- * `mpfr.pdf' or `pdf'
-
- Create a PDF version of the manual, in `mpfr.pdf'.
-
- * `mpfr.dvi' or `dvi'
-
- Create a DVI version of the manual, in `mpfr.dvi'.
-
- * `mpfr.ps' or `ps'
-
- Create a Postscript version of the manual, in `mpfr.ps'.
-
- * `mpfr.html' or `html'
-
- Create a HTML version of the manual, in several pages in the
- directory `mpfr.html'; if you want only one output HTML file, then
- type `makeinfo --html --no-split mpfr.texi' instead.
-
- * `clean'
-
- Delete all object files and archive files, but not the
- configuration files.
-
- * `distclean'
-
- Delete all files not included in the distribution.
-
- * `uninstall'
-
- Delete all files copied by `make install'.
-
-2.3 Build Problems
-==================
-
-In case of problem, please read the `INSTALL' file carefully before
-reporting a bug, in particular section "In case of problem". Some
-problems are due to bad configuration on the user side (not specific to
-MPFR). Problems are also mentioned in the FAQ
-`http://www.mpfr.org/faq.html'.
-
- Please report problems to `mpfr@loria.fr'. *Note Reporting Bugs::.
-Some bug fixes are available on the MPFR 2.4.1 web page
-`http://www.mpfr.org/mpfr-2.4.1/'.
-
-2.4 Getting the Latest Version of MPFR
-======================================
-
-The latest version of MPFR is available from
-`ftp://ftp.gnu.org/gnu/mpfr/' or `http://www.mpfr.org/'.
-
-\1f
-File: mpfr.info, Node: Reporting Bugs, Next: MPFR Basics, Prev: Installing MPFR, Up: Top
-
-3 Reporting Bugs
-****************
-
-If you think you have found a bug in the MPFR library, first have a look
-on the MPFR 2.4.1 web page `http://www.mpfr.org/mpfr-2.4.1/' and the
-FAQ `http://www.mpfr.org/faq.html': perhaps this bug is already known,
-in which case you may find there a workaround for it. Otherwise, please
-investigate and report it. We have made this library available to you,
-and it is not to ask too much from you, to ask you to report the bugs
-that you find.
-
- There are a few things you should think about when you put your bug
-report together.
-
- You have to send us a test case that makes it possible for us to
-reproduce the bug. Include instructions on how to run the test case.
-
- You also have to explain what is wrong; if you get a crash, or if
-the results printed are incorrect and in that case, in what way.
-
- Please include compiler version information in your bug report. This
-can be extracted using `cc -V' on some machines, or, if you're using
-gcc, `gcc -v'. Also, include the output from `uname -a' and the MPFR
-version (the GMP version may be useful too).
-
- If your bug report is good, we will do our best to help you to get a
-corrected version of the library; if the bug report is poor, we will
-not do anything about it (aside of chiding you to send better bug
-reports).
-
- Send your bug report to: `mpfr@loria.fr'.
-
- If you think something in this manual is unclear, or downright
-incorrect, or if the language needs to be improved, please send a note
-to the same address.
-
-\1f
-File: mpfr.info, Node: MPFR Basics, Next: MPFR Interface, Prev: Reporting Bugs, Up: Top
-
-4 MPFR Basics
-*************
-
-4.1 Headers and Libraries
-=========================
-
-All declarations needed to use MPFR are collected in the include file
-`mpfr.h'. It is designed to work with both C and C++ compilers. You
-should include that file in any program using the MPFR library:
-
- #include <mpfr.h>
-
- Note however that prototypes for MPFR functions with `FILE *'
-parameters are provided only if `<stdio.h>' is included too (before
-`mpfr.h').
-
- #include <stdio.h>
- #include <mpfr.h>
-
- Likewise `<stdarg.h>' (or `<varargs.h>') is required for prototypes
-with `va_list' parameters, such as `mpfr_vprintf'.
-
- You can avoid the use of MPFR macros encapsulating functions by
-defining the `MPFR_USE_NO_MACRO' macro before `mpfr.h' is included. In
-general this should not be necessary, but this can be useful when
-debugging user code: with some macros, the compiler may emit spurious
-warnings with some warning options, and macros can prevent some
-prototype checking.
-
- All programs using MPFR must link against both `libmpfr' and
-`libgmp' libraries. On a typical Unix-like system this can be done
-with `-lmpfr -lgmp' (in that order), for example
-
- gcc myprogram.c -lmpfr -lgmp
-
- MPFR is built using Libtool and an application can use that to link
-if desired, *note GNU Libtool: (libtool.info)Top.
-
- If MPFR has been installed to a non-standard location, then it may be
-necessary to set up environment variables such as `C_INCLUDE_PATH' and
-`LIBRARY_PATH', or use `-I' and `-L' compiler options, in order to
-point to the right directories. For a shared library, it may also be
-necessary to set up some sort of run-time library path (e.g.,
-`LD_LIBRARY_PATH') on some systems. Please read the `INSTALL' file for
-additional information.
-
-4.2 Nomenclature and Types
-==========================
-
-A "floating-point number" or "float" for short, is an arbitrary
-precision significand (also called mantissa) with a limited precision
-exponent. The C data type for such objects is `mpfr_t' (internally
-defined as a one-element array of a structure, and `mpfr_ptr' is the C
-data type representing a pointer to this structure). A floating-point
-number can have three special values: Not-a-Number (NaN) or plus or
-minus Infinity. NaN represents an uninitialized object, the result of
-an invalid operation (like 0 divided by 0), or a value that cannot be
-determined (like +Infinity minus +Infinity). Moreover, like in the IEEE
-754-1985 standard, zero is signed, i.e. there are both +0 and -0; the
-behavior is the same as in the IEEE 754-1985 standard and it is
-generalized to the other functions supported by MPFR.
-
-The "precision" is the number of bits used to represent the significand
-of a floating-point number; the corresponding C data type is
-`mp_prec_t'. The precision can be any integer between `MPFR_PREC_MIN'
-and `MPFR_PREC_MAX'. In the current implementation, `MPFR_PREC_MIN' is
-equal to 2.
-
- Warning! MPFR needs to increase the precision internally, in order to
-provide accurate results (and in particular, correct rounding). Do not
-attempt to set the precision to any value near `MPFR_PREC_MAX',
-otherwise MPFR will abort due to an assertion failure. Moreover, you
-may reach some memory limit on your platform, in which case the program
-may abort, crash or have undefined behavior (depending on your C
-implementation).
-
-The "rounding mode" specifies the way to round the result of a
-floating-point operation, in case the exact result can not be
-represented exactly in the destination significand; the corresponding C
-data type is `mp_rnd_t'.
-
-A "limb" means the part of a multi-precision number that fits in a
-single word. (We chose this word because a limb of the human body is
-analogous to a digit, only larger, and containing several digits.)
-Normally a limb contains 32 or 64 bits. The C data type for a limb is
-`mp_limb_t'.
-
-4.3 Function Classes
-====================
-
-There is only one class of functions in the MPFR library:
-
- 1. Functions for floating-point arithmetic, with names beginning with
- `mpfr_'. The associated type is `mpfr_t'.
-
-4.4 MPFR Variable Conventions
-=============================
-
-As a general rule, all MPFR functions expect output arguments before
-input arguments. This notation is based on an analogy with the
-assignment operator.
-
- MPFR allows you to use the same variable for both input and output
-in the same expression. For example, the main function for
-floating-point multiplication, `mpfr_mul', can be used like this:
-`mpfr_mul (x, x, x, rnd_mode)'. This computes the square of X with
-rounding mode `rnd_mode' and puts the result back in X.
-
- Before you can assign to an MPFR variable, you need to initialize it
-by calling one of the special initialization functions. When you're
-done with a variable, you need to clear it out, using one of the
-functions for that purpose.
-
- A variable should only be initialized once, or at least cleared out
-between each initialization. After a variable has been initialized, it
-may be assigned to any number of times.
-
- For efficiency reasons, avoid to initialize and clear out a variable
-in loops. Instead, initialize it before entering the loop, and clear
-it out after the loop has exited.
-
- You do not need to be concerned about allocating additional space
-for MPFR variables, since any variable has a significand of fixed size.
-Hence unless you change its precision, or clear and reinitialize it, a
-floating-point variable will have the same allocated space during all
-its life.
-
-4.5 Rounding Modes
-==================
-
-The following four rounding modes are supported:
-
- * `GMP_RNDN': round to nearest
-
- * `GMP_RNDZ': round toward zero
-
- * `GMP_RNDU': round toward plus infinity
-
- * `GMP_RNDD': round toward minus infinity
-
- The `round to nearest' mode works as in the IEEE 754-1985 standard:
-in case the number to be rounded lies exactly in the middle of two
-representable numbers, it is rounded to the one with the least
-significant bit set to zero. For example, the number 5/2, which is
-represented by (10.1) in binary, is rounded to (10.0)=2 with a
-precision of two bits, and not to (11.0)=3. This rule avoids the
-"drift" phenomenon mentioned by Knuth in volume 2 of The Art of
-Computer Programming (Section 4.2.2).
-
- Most MPFR functions take as first argument the destination variable,
-as second and following arguments the input variables, as last argument
-a rounding mode, and have a return value of type `int', called the
-"ternary value". The value stored in the destination variable is
-correctly rounded, i.e. MPFR behaves as if it computed the result with
-an infinite precision, then rounded it to the precision of this
-variable. The input variables are regarded as exact (in particular,
-their precision does not affect the result).
-
- As a consequence, in case of a non-zero real rounded result, the
-error on the result is less or equal to 1/2 ulp (unit in the last
-place) of the target in the rounding to nearest mode, and less than 1
-ulp of the target in the directed rounding modes (a ulp is the weight
-of the least significant represented bit of the target after rounding).
-
- Unless documented otherwise, functions returning an `int' return a
-ternary value. If the ternary value is zero, it means that the value
-stored in the destination variable is the exact result of the
-corresponding mathematical function. If the ternary value is positive
-(resp. negative), it means the value stored in the destination variable
-is greater (resp. lower) than the exact result. For example with the
-`GMP_RNDU' rounding mode, the ternary value is usually positive, except
-when the result is exact, in which case it is zero. In the case of an
-infinite result, it is considered as inexact when it was obtained by
-overflow, and exact otherwise. A NaN result (Not-a-Number) always
-corresponds to an exact return value. The opposite of a returned
-ternary value is guaranteed to be representable in an `int'.
-
- Unless documented otherwise, functions returning a `1' (or any other
-value specified in this manual) for special cases (like `acos(0)')
-should return an overflow or an underflow if `1' is not representable
-in the current exponent range.
-
-4.6 Floating-Point Values on Special Numbers
-============================================
-
-This section specifies the floating-point values (of type `mpfr_t')
-returned by MPFR functions. For functions returning several values (like
-`mpfr_sin_cos'), the rules apply to each result separately.
-
- Functions can have one or several input arguments. An input point is
-a mapping from these input arguments to the set of the MPFR numbers.
-When none of its components are NaN, an input point can also be seen as
-a tuple in the extended real numbers (the set of the real numbers with
-both infinities).
-
- When the input point is in the domain of the mathematical function,
-the result is rounded as described in Section "Rounding Modes" (but see
-below for the specification of the sign of an exact zero). Otherwise
-the general rules from this section apply unless stated otherwise in
-the description of the MPFR function (*note MPFR Interface::).
-
- When the input point is not in the domain of the mathematical
-function but is in its closure in the extended real numbers and the
-function can be extended by continuity, the result is the obtained
-limit. Examples: `mpfr_hypot' on (+Inf,0) gives +Inf. But `mpfr_pow'
-cannot be defined on (1,+Inf) using this rule, as one can find
-sequences (X_N,Y_N) such that X_N goes to 1, Y_N goes to +Inf and X_N
-to the Y_N goes to any positive value when N goes to the infinity.
-
- When the input point is in the closure of the domain of the
-mathematical function and an input argument is +0 (resp. -0), one
-considers the limit when the corresponding argument approaches 0 from
-above (resp. below). If the limit is not defined (e.g., `mpfr_log' on
--0), the behavior must be specified in the description of the MPFR
-function.
-
- When the result is equal to 0, its sign is determined by considering
-the limit as if the input point were not in the domain: If one
-approaches 0 from above (resp. below), the result is +0 (resp. -0). In
-the other cases, the sign must be specified in the description of the
-MPFR function. Example: `mpfr_sin' on +0 gives +0.
-
- When the input point is not in the closure of the domain of the
-function, the result is NaN. Example: `mpfr_sqrt' on -17 gives NaN.
-
- When an input argument is NaN, the result is NaN, possibly except
-when a partial function is constant on the finite floating-point
-numbers; such a case is always explicitly specified in *note MPFR
-Interface::. Example: `mpfr_hypot' on (NaN,0) gives NaN, but
-`mpfr_hypot' on (NaN,+Inf) gives +Inf (as specified in *note Special
-Functions::), since for any finite input X, `mpfr_hypot' on (X,+Inf)
-gives +Inf.
-
-4.7 Exceptions
-==============
-
-MPFR supports 5 exception types:
-
- * Underflow: An underflow occurs when the exact result of a function
- is a non-zero real number and the result obtained after the
- rounding, assuming an unbounded exponent range (for the rounding),
- has an exponent smaller than the minimum exponent of the current
- range. In the round-to-nearest mode, the halfway case is rounded
- toward zero.
-
- Note: This is not the single definition of the underflow. MPFR
- chooses to consider the underflow after rounding. The underflow
- before rounding can also be defined. For instance, consider a
- function that has the exact result 7 multiplied by two to the power
- E-4, where E is the smallest exponent (for a significand between
- 1/2 and 1) in the current range, with a 2-bit target precision and
- rounding toward plus infinity. The exact result has the exponent
- E-1. With the underflow before rounding, such a function call
- would yield an underflow, as E-1 is outside the current exponent
- range. However, MPFR first considers the rounded result assuming
- an unbounded exponent range. The exact result cannot be
- represented exactly in precision 2, and here, it is rounded to 0.5
- times 2 to E, which is representable in the current exponent
- range. As a consequence, this will not yield an underflow in MPFR.
-
- * Overflow: An overflow occurs when the exact result of a function
- is a non-zero real number and the result obtained after the
- rounding, assuming an unbounded exponent range (for the rounding),
- has an exponent larger than the maximum exponent of the current
- range. In the round-to-nearest mode, the result is infinite.
-
- * NaN: A NaN exception occurs when the result of a function is a NaN.
-
- * Inexact: An inexact exception occurs when the result of a function
- cannot be represented exactly and must be rounded.
-
- * Range error: A range exception occurs when a function that does
- not return a MPFR number (such as comparisons and conversions to
- an integer) has an invalid result (e.g. an argument is NaN in
- `mpfr_cmp' or in a conversion to an integer).
-
-
- MPFR has a global flag for each exception, which can be cleared, set
-or tested by functions described in *note Exception Related Functions::.
-
- Differences with the ISO C99 standard:
-
- * In C, only quiet NaNs are specified, and a NaN propagation does not
- raise an invalid exception. Unless explicitly stated otherwise,
- MPFR sets the NaN flag whenever a NaN is generated, even when a
- NaN is propagated (e.g. in NaN + NaN), as if all NaNs were
- signaling.
-
- * An invalid exception in C corresponds to either a NaN exception or
- a range error in MPFR.
-
-
-4.8 Memory Handling
-===================
-
-MPFR functions may create caches, e.g. when computing constants such as
-Pi, either because the user has called a function like `mpfr_const_pi'
-directly or because such a function was called internally by the MPFR
-library itself to compute some other function.
-
- At any time, the user can free the various caches with
-`mpfr_free_cache'. It is strongly advised to do that before terminating
-a thread, or before exiting when using tools like `valgrind' (to avoid
-memory leaks being reported).
-
- MPFR internal data such as flags, the exponent range, the default
-precision and rounding mode, and caches (i.e., data that are not
-accessed via parameters) are either global (if MPFR has not been
-compiled as thread safe) or per-thread (thread local storage).
-
-\1f
-File: mpfr.info, Node: MPFR Interface, Next: Contributors, Prev: MPFR Basics, Up: Top
-
-5 MPFR Interface
-****************
-
-The floating-point functions expect arguments of type `mpfr_t'.
-
- The MPFR floating-point functions have an interface that is similar
-to the GNU MP integer functions. The function prefix for
-floating-point operations is `mpfr_'.
-
- There is one significant characteristic of floating-point numbers
-that has motivated a difference between this function class and other
-GNU MP function classes: the inherent inexactness of floating-point
-arithmetic. The user has to specify the precision for each variable.
-A computation that assigns a variable will take place with the
-precision of the assigned variable; the cost of that computation should
-not depend from the precision of variables used as input (on average).
-
- The semantics of a calculation in MPFR is specified as follows:
-Compute the requested operation exactly (with "infinite accuracy"), and
-round the result to the precision of the destination variable, with the
-given rounding mode. The MPFR floating-point functions are intended to
-be a smooth extension of the IEEE 754-1985 arithmetic. The results
-obtained on one computer should not differ from the results obtained on
-a computer with a different word size.
-
- MPFR does not keep track of the accuracy of a computation. This is
-left to the user or to a higher layer. As a consequence, if two
-variables are used to store only a few significant bits, and their
-product is stored in a variable with large precision, then MPFR will
-still compute the result with full precision.
-
- The value of the standard C macro `errno' may be set to non-zero by
-any MPFR function or macro, whether or not there is an error.
-
-* Menu:
-
-* Initialization Functions::
-* Assignment Functions::
-* Combined Initialization and Assignment Functions::
-* Conversion Functions::
-* Basic Arithmetic Functions::
-* Comparison Functions::
-* Special Functions::
-* Input and Output Functions::
-* Formatted Output Functions::
-* Integer Related Functions::
-* Rounding Related Functions::
-* Miscellaneous Functions::
-* Exception Related Functions::
-* Compatibility with MPF::
-* Custom Interface::
-* Internals::
-
-\1f
-File: mpfr.info, Node: Initialization Functions, Next: Assignment Functions, Prev: MPFR Interface, Up: MPFR Interface
-
-5.1 Initialization Functions
-============================
-
-An `mpfr_t' object must be initialized before storing the first value in
-it. The functions `mpfr_init' and `mpfr_init2' are used for that
-purpose.
-
- -- Function: void mpfr_init2 (mpfr_t X, mp_prec_t PREC)
- Initialize X, set its precision to be *exactly* PREC bits and its
- value to NaN. (Warning: the corresponding `mpf' functions
- initialize to zero instead.)
-
- Normally, a variable should be initialized once only or at least
- be cleared, using `mpfr_clear', between initializations. To
- change the precision of a variable which has already been
- initialized, use `mpfr_set_prec'. The precision PREC must be an
- integer between `MPFR_PREC_MIN' and `MPFR_PREC_MAX' (otherwise the
- behavior is undefined).
-
- -- Function: void mpfr_inits2 (mp_prec_t PREC, mpfr_t X, ...)
- Initialize all the `mpfr_t' variables of the given `va_list', set
- their precision to be *exactly* PREC bits and their value to NaN.
- See `mpfr_init2' for more details. The `va_list' is assumed to be
- composed only of type `mpfr_t' (or equivalently `mpfr_ptr'). It
- begins from X. It ends when it encounters a null pointer (whose
- type must also be `mpfr_ptr').
-
- -- Function: void mpfr_clear (mpfr_t X)
- Free the space occupied by X. Make sure to call this function for
- all `mpfr_t' variables when you are done with them.
-
- -- Function: void mpfr_clears (mpfr_t X, ...)
- Free the space occupied by all the `mpfr_t' variables of the given
- `va_list'. See `mpfr_clear' for more details. The `va_list' is
- assumed to be composed only of type `mpfr_t' (or equivalently
- `mpfr_ptr'). It begins from X. It ends when it encounters a null
- pointer (whose type must also be `mpfr_ptr').
-
- Here is an example of how to use multiple initialization functions:
-
- {
- mpfr_t x, y, z, t;
- mpfr_inits2 (256, x, y, z, t, (mpfr_ptr) 0);
- ...
- mpfr_clears (x, y, z, t, (mpfr_ptr) 0);
- }
-
- -- Function: void mpfr_init (mpfr_t X)
- Initialize X and set its value to NaN.
-
- Normally, a variable should be initialized once only or at least
- be cleared, using `mpfr_clear', between initializations. The
- precision of X is the default precision, which can be changed by a
- call to `mpfr_set_default_prec'.
-
- Warning! In a given program, some other libraries might change the
- default precision and not restore it. Thus it is safer to use
- `mpfr_init2'.
-
- -- Function: void mpfr_inits (mpfr_t X, ...)
- Initialize all the `mpfr_t' variables of the given `va_list', set
- their precision to be the default precision and their value to NaN.
- See `mpfr_init' for more details. The `va_list' is assumed to be
- composed only of type `mpfr_t' (or equivalently `mpfr_ptr'). It
- begins from X. It ends when it encounters a null pointer (whose
- type must also be `mpfr_ptr').
-
- Warning! In a given program, some other libraries might change the
- default precision and not restore it. Thus it is safer to use
- `mpfr_inits2'.
-
- -- Macro: MPFR_DECL_INIT (NAME, PREC)
- This macro declares NAME as an automatic variable of type `mpfr_t',
- initializes it and sets its precision to be *exactly* PREC bits
- and its value to NaN. NAME must be a valid identifier. You must
- use this macro in the declaration section. This macro is much
- faster than using `mpfr_init2' but has some drawbacks:
-
- * You *must not* call `mpfr_clear' with variables created with
- this macro (the storage is allocated at the point of
- declaration and deallocated when the brace-level is exited).
-
- * You *cannot* change their precision.
-
- * You *should not* create variables with huge precision with
- this macro.
-
- * Your compiler must support `Non-Constant Initializers'
- (standard in C++ and ISO C99) and `Token Pasting' (standard
- in ISO C89). If PREC is not a constant expression, your
- compiler must support `variable-length automatic arrays'
- (standard in ISO C99). `GCC 2.95.3' and above supports all
- these features. If you compile your program with gcc in c89
- mode and with `-pedantic', you may want to define the
- `MPFR_USE_EXTENSION' macro to avoid warnings due to the
- `MPFR_DECL_INIT' implementation.
-
- -- Function: void mpfr_set_default_prec (mp_prec_t PREC)
- Set the default precision to be *exactly* PREC bits. The
- precision of a variable means the number of bits used to store its
- significand. All subsequent calls to `mpfr_init' will use this
- precision, but previously initialized variables are unaffected.
- This default precision is set to 53 bits initially. The precision
- can be any integer between `MPFR_PREC_MIN' and `MPFR_PREC_MAX'.
-
- -- Function: mp_prec_t mpfr_get_default_prec (void)
- Return the default MPFR precision in bits.
-
- Here is an example on how to initialize floating-point variables:
-
- {
- mpfr_t x, y;
- mpfr_init (x); /* use default precision */
- mpfr_init2 (y, 256); /* precision _exactly_ 256 bits */
- ...
- /* When the program is about to exit, do ... */
- mpfr_clear (x);
- mpfr_clear (y);
- mpfr_free_cache ();
- }
-
- The following functions are useful for changing the precision during
-a calculation. A typical use would be for adjusting the precision
-gradually in iterative algorithms like Newton-Raphson, making the
-computation precision closely match the actual accurate part of the
-numbers.
-
- -- Function: void mpfr_set_prec (mpfr_t X, mp_prec_t PREC)
- Reset the precision of X to be *exactly* PREC bits, and set its
- value to NaN. The previous value stored in X is lost. It is
- equivalent to a call to `mpfr_clear(x)' followed by a call to
- `mpfr_init2(x, prec)', but more efficient as no allocation is done
- in case the current allocated space for the significand of X is
- enough. The precision PREC can be any integer between
- `MPFR_PREC_MIN' and `MPFR_PREC_MAX'.
-
- In case you want to keep the previous value stored in X, use
- `mpfr_prec_round' instead.
-
- -- Function: mp_prec_t mpfr_get_prec (mpfr_t X)
- Return the precision actually used for assignments of X, i.e. the
- number of bits used to store its significand.
-
-\1f
-File: mpfr.info, Node: Assignment Functions, Next: Combined Initialization and Assignment Functions, Prev: Initialization Functions, Up: MPFR Interface
-
-5.2 Assignment Functions
-========================
-
-These functions assign new values to already initialized floats (*note
-Initialization Functions::). When using any functions using `intmax_t',
-you must include `<stdint.h>' or `<inttypes.h>' before `mpfr.h', to
-allow `mpfr.h' to define prototypes for these functions.
-
- -- Function: int mpfr_set (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_set_ui (mpfr_t ROP, unsigned long int OP,
- mp_rnd_t RND)
- -- Function: int mpfr_set_si (mpfr_t ROP, long int OP, mp_rnd_t RND)
- -- Function: int mpfr_set_uj (mpfr_t ROP, uintmax_t OP, mp_rnd_t RND)
- -- Function: int mpfr_set_sj (mpfr_t ROP, intmax_t OP, mp_rnd_t RND)
- -- Function: int mpfr_set_d (mpfr_t ROP, double OP, mp_rnd_t RND)
- -- Function: int mpfr_set_ld (mpfr_t ROP, long double OP, mp_rnd_t RND)
- -- Function: int mpfr_set_decimal64 (mpfr_t ROP, _Decimal64 OP,
- mp_rnd_t RND)
- -- Function: int mpfr_set_z (mpfr_t ROP, mpz_t OP, mp_rnd_t RND)
- -- Function: int mpfr_set_q (mpfr_t ROP, mpq_t OP, mp_rnd_t RND)
- -- Function: int mpfr_set_f (mpfr_t ROP, mpf_t OP, mp_rnd_t RND)
- Set the value of ROP from OP, rounded toward the given direction
- RND. Note that the input 0 is converted to +0 by `mpfr_set_ui',
- `mpfr_set_si', `mpfr_set_sj', `mpfr_set_uj', `mpfr_set_z',
- `mpfr_set_q' and `mpfr_set_f', regardless of the rounding mode.
- If the system does not support the IEEE-754 standard, `mpfr_set_d',
- `mpfr_set_ld' and `mpfr_set_decimal64' might not preserve the
- signed zeros. The `mpfr_set_decimal64' function is built only
- with the configure option `--enable-decimal-float', which also
- requires `--with-gmp-build', and when the compiler or system
- provides the `_Decimal64' data type (GCC version 4.2.0 is known to
- support this data type, but only when configured with
- `--enable-decimal-float' too). `mpfr_set_q' might not be able to
- work if the numerator (or the denominator) can not be
- representable as a `mpfr_t'.
-
- Note: If you want to store a floating-point constant to a `mpfr_t',
- you should use `mpfr_set_str' (or one of the MPFR constant
- functions, such as `mpfr_const_pi' for Pi) instead of `mpfr_set_d',
- `mpfr_set_ld' or `mpfr_set_decimal64'. Otherwise the
- floating-point constant will be first converted into a
- reduced-precision (e.g., 53-bit) binary number before MPFR can
- work with it.
-
- -- Function: int mpfr_set_ui_2exp (mpfr_t ROP, unsigned long int OP,
- mp_exp_t E, mp_rnd_t RND)
- -- Function: int mpfr_set_si_2exp (mpfr_t ROP, long int OP, mp_exp_t
- E, mp_rnd_t RND)
- -- Function: int mpfr_set_uj_2exp (mpfr_t ROP, uintmax_t OP, intmax_t
- E, mp_rnd_t RND)
- -- Function: int mpfr_set_sj_2exp (mpfr_t ROP, intmax_t OP, intmax_t
- E, mp_rnd_t RND)
- Set the value of ROP from OP multiplied by two to the power E,
- rounded toward the given direction RND. Note that the input 0 is
- converted to +0.
-
- -- Function: int mpfr_set_str (mpfr_t ROP, const char *S, int BASE,
- mp_rnd_t RND)
- Set ROP to the value of the string S in base BASE, rounded in the
- direction RND. See the documentation of `mpfr_strtofr' for a
- detailed description of the valid string formats. Contrary to
- `mpfr_strtofr', `mpfr_set_str' requires the _whole_ string to
- represent a valid floating-point number. This function returns 0
- if the entire string up to the final null character is a valid
- number in base BASE; otherwise it returns -1, and ROP may have
- changed.
-
- -- Function: int mpfr_strtofr (mpfr_t ROP, const char *NPTR, char
- **ENDPTR, int BASE, mp_rnd_t RND)
- Read a floating-point number from a string NPTR in base BASE,
- rounded in the direction RND; BASE must be either 0 (to detect the
- base, as described below) or a number from 2 to 36 (otherwise the
- behavior is undefined). If NPTR starts with valid data, the result
- is stored in ROP and `*ENDPTR' points to the character just after
- the valid data (if ENDPTR is not a null pointer); otherwise ROP is
- set to zero and the value of NPTR is stored in the location
- referenced by ENDPTR (if ENDPTR is not a null pointer). The usual
- ternary value is returned.
-
- Parsing follows the standard C `strtod' function with some
- extensions. Case is ignored. After optional leading whitespace,
- one has a subject sequence consisting of an optional sign (`+' or
- `-'), and either numeric data or special data. The subject
- sequence is defined as the longest initial subsequence of the
- input string, starting with the first non-whitespace character,
- that is of the expected form.
-
- The form of numeric data is a non-empty sequence of significand
- digits with an optional decimal point, and an optional exponent
- consisting of an exponent prefix followed by an optional sign and
- a non-empty sequence of decimal digits. A significand digit is
- either a decimal digit or a Latin letter (62 possible characters),
- with `a' = 10, `b' = 11, ..., `z' = 35; its value must be strictly
- less than the base. The decimal point can be either the one
- defined by the current locale or the period (the first one is
- accepted for consistency with the C standard and the practice, the
- second one is accepted to allow the programmer to provide MPFR
- numbers from strings in a way that does not depend on the current
- locale). The exponent prefix can be `e' or `E' for bases up to
- 10, or `@' in any base; it indicates a multiplication by a power
- of the base. In bases 2 and 16, the exponent prefix can also be
- `p' or `P', in which case it introduces a binary exponent: it
- indicates a multiplication by a power of 2 (there is a difference
- only for base 16). The value of an exponent is always written in
- base 10. In base 2, the significand can start with `0b' or `0B',
- and in base 16, it can start with `0x' or `0X'.
-
- If the argument BASE is 0, then the base is automatically detected
- as follows. If the significand starts with `0b' or `0B', base 2 is
- assumed. If the significand starts with `0x' or `0X', base 16 is
- assumed. Otherwise base 10 is assumed.
-
- Note: The exponent must contain at least a digit. Otherwise the
- possible exponent prefix and sign are not part of the number
- (which ends with the significand). Similarly, if `0b', `0B', `0x'
- or `0X' is not followed by a binary/hexadecimal digit, then the
- subject sequence stops at the character `0'.
-
- Special data (for infinities and NaN) can be `@inf@' or
- `@nan@(n-char-sequence)', and if BASE <= 16, it can also be
- `infinity', `inf', `nan' or `nan(n-char-sequence)', all case
- insensitive. A `n-char-sequence' is a non-empty string containing
- only digits, Latin letters and the underscore (0, 1, 2, ..., 9, a,
- b, ..., z, A, B, ..., Z, _). Note: one has an optional sign for
- all data, even NaN.
-
-
- -- Function: void mpfr_set_inf (mpfr_t X, int SIGN)
- -- Function: void mpfr_set_nan (mpfr_t X)
- Set the variable X to infinity or NaN (Not-a-Number) respectively.
- In `mpfr_set_inf', X is set to plus infinity iff SIGN is
- nonnegative.
-
- -- Function: void mpfr_swap (mpfr_t X, mpfr_t Y)
- Swap the values X and Y efficiently. Warning: the precisions are
- exchanged too; in case the precisions are different, `mpfr_swap'
- is thus not equivalent to three `mpfr_set' calls using a third
- auxiliary variable.
-
-\1f
-File: mpfr.info, Node: Combined Initialization and Assignment Functions, Next: Conversion Functions, Prev: Assignment Functions, Up: MPFR Interface
-
-5.3 Combined Initialization and Assignment Functions
-====================================================
-
- -- Macro: int mpfr_init_set (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Macro: int mpfr_init_set_ui (mpfr_t ROP, unsigned long int OP,
- mp_rnd_t RND)
- -- Macro: int mpfr_init_set_si (mpfr_t ROP, signed long int OP,
- mp_rnd_t RND)
- -- Macro: int mpfr_init_set_d (mpfr_t ROP, double OP, mp_rnd_t RND)
- -- Macro: int mpfr_init_set_ld (mpfr_t ROP, long double OP, mp_rnd_t
- RND)
- -- Macro: int mpfr_init_set_z (mpfr_t ROP, mpz_t OP, mp_rnd_t RND)
- -- Macro: int mpfr_init_set_q (mpfr_t ROP, mpq_t OP, mp_rnd_t RND)
- -- Macro: int mpfr_init_set_f (mpfr_t ROP, mpf_t OP, mp_rnd_t RND)
- Initialize ROP and set its value from OP, rounded in the direction
- RND. The precision of ROP will be taken from the active default
- precision, as set by `mpfr_set_default_prec'.
-
- -- Function: int mpfr_init_set_str (mpfr_t X, const char *S, int BASE,
- mp_rnd_t RND)
- Initialize X and set its value from the string S in base BASE,
- rounded in the direction RND. See `mpfr_set_str'.
-
-\1f
-File: mpfr.info, Node: Conversion Functions, Next: Basic Arithmetic Functions, Prev: Combined Initialization and Assignment Functions, Up: MPFR Interface
-
-5.4 Conversion Functions
-========================
-
- -- Function: double mpfr_get_d (mpfr_t OP, mp_rnd_t RND)
- -- Function: long double mpfr_get_ld (mpfr_t OP, mp_rnd_t RND)
- -- Function: _Decimal64 mpfr_get_decimal64 (mpfr_t OP, mp_rnd_t RND)
- Convert OP to a `double' (respectively `_Decimal64' or `long
- double'), using the rounding mode RND. If OP is NaN, some fixed
- NaN (either quiet or signaling) or the result of 0.0/0.0 is
- returned. If OP is ±Inf, an infinity of the same sign or the
- result of ±1.0/0.0 is returned. If OP is zero, these functions
- return a zero, trying to preserve its sign, if possible. The
- `mpfr_get_decimal64' function is built only under some conditions:
- see the documentation of `mpfr_set_decimal64'.
-
- -- Function: double mpfr_get_d_2exp (long *EXP, mpfr_t OP, mp_rnd_t
- RND)
- -- Function: long double mpfr_get_ld_2exp (long *EXP, mpfr_t OP,
- mp_rnd_t RND)
- Return D and set EXP such that 0.5<=abs(D)<1 and D times 2 raised
- to EXP equals OP rounded to double (resp. long double) precision,
- using the given rounding mode. If OP is zero, then a zero of the
- same sign (or an unsigned zero, if the implementation does not
- have signed zeros) is returned, and EXP is set to 0. If OP is NaN
- or an infinity, then the corresponding double precision (resp.
- long-double precision) value is returned, and EXP is undefined.
-
- -- Function: long mpfr_get_si (mpfr_t OP, mp_rnd_t RND)
- -- Function: unsigned long mpfr_get_ui (mpfr_t OP, mp_rnd_t RND)
- -- Function: intmax_t mpfr_get_sj (mpfr_t OP, mp_rnd_t RND)
- -- Function: uintmax_t mpfr_get_uj (mpfr_t OP, mp_rnd_t RND)
- Convert OP to a `long', an `unsigned long', an `intmax_t' or an
- `uintmax_t' (respectively) after rounding it with respect to RND.
- If OP is NaN, the result is undefined. If OP is too big for the
- return type, it returns the maximum or the minimum of the
- corresponding C type, depending on the direction of the overflow.
- The _erange_ flag is set too. See also `mpfr_fits_slong_p',
- `mpfr_fits_ulong_p', `mpfr_fits_intmax_p' and
- `mpfr_fits_uintmax_p'.
-
- -- Function: mp_exp_t mpfr_get_z_exp (mpz_t ROP, mpfr_t OP)
- Put the scaled significand of OP (regarded as an integer, with the
- precision of OP) into ROP, and return the exponent EXP (which may
- be outside the current exponent range) such that OP exactly equals
- ROP multiplied by two exponent EXP. If the exponent is not
- representable in the `mp_exp_t' type, the behavior is undefined.
-
- -- Function: void mpfr_get_z (mpz_t ROP, mpfr_t OP, mp_rnd_t RND)
- Convert OP to a `mpz_t', after rounding it with respect to RND. If
- OP is NaN or Inf, the result is undefined.
-
- -- Function: int mpfr_get_f (mpf_t ROP, mpfr_t OP, mp_rnd_t RND)
- Convert OP to a `mpf_t', after rounding it with respect to RND.
- Return zero iff no error occurred, in particular a non-zero value
- is returned if OP is NaN or Inf, which do not exist in `mpf'.
-
- -- Function: char * mpfr_get_str (char *STR, mp_exp_t *EXPPTR, int B,
- size_t N, mpfr_t OP, mp_rnd_t RND)
- Convert OP to a string of digits in base B, with rounding in the
- direction RND, where N is either zero (see below) or the number of
- significant digits; in the latter case, N must be greater or equal
- to 2. The base may vary from 2 to 36.
-
- The generated string is a fraction, with an implicit radix point
- immediately to the left of the first digit. For example, the
- number -3.1416 would be returned as "-31416" in the string and 1
- written at EXPPTR. If RND is to nearest, and OP is exactly in the
- middle of two possible outputs, the one with an even last digit is
- chosen (for an odd base, this may not correspond to an even
- significand).
-
- If N is zero, the number of digits of the significand is chosen
- large enough so that re-reading the printed value with the same
- precision, assuming both output and input use rounding to nearest,
- will recover the original value of OP. More precisely, in most
- cases, the chosen precision of STR is the minimal precision
- depending on N and B only that satisfies the above property, i.e.,
- m = 1 + ceil(N*log(2)/log(B)), but in some very rare cases, it
- might be m+1.
-
- If STR is a null pointer, space for the significand is allocated
- using the current allocation function, and a pointer to the string
- is returned. To free the returned string, you must use
- `mpfr_free_str'.
-
- If STR is not a null pointer, it should point to a block of storage
- large enough for the significand, i.e., at least `max(N + 2, 7)'.
- The extra two bytes are for a possible minus sign, and for the
- terminating null character.
-
- If the input number is an ordinary number, the exponent is written
- through the pointer EXPPTR (the current minimal exponent for 0).
-
- A pointer to the string is returned, unless there is an error, in
- which case a null pointer is returned.
-
- -- Function: void mpfr_free_str (char *STR)
- Free a string allocated by `mpfr_get_str' using the current
- unallocation function (preliminary interface). The block is
- assumed to be `strlen(STR)+1' bytes. For more information about
- how it is done: *note Custom Allocation: (gmp.info)Custom
- Allocation.
-
- -- Function: int mpfr_fits_ulong_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_slong_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_uint_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_sint_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_ushort_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_sshort_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_intmax_p (mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_fits_uintmax_p (mpfr_t OP, mp_rnd_t RND)
- Return non-zero if OP would fit in the respective C data type, when
- rounded to an integer in the direction RND.
-
-\1f
-File: mpfr.info, Node: Basic Arithmetic Functions, Next: Comparison Functions, Prev: Conversion Functions, Up: MPFR Interface
-
-5.5 Basic Arithmetic Functions
-==============================
-
- -- Function: int mpfr_add (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_add_ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_add_si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_add_d (mpfr_t ROP, mpfr_t OP1, double OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_add_z (mpfr_t ROP, mpfr_t OP1, mpz_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_add_q (mpfr_t ROP, mpfr_t OP1, mpq_t OP2,
- mp_rnd_t RND)
- Set ROP to OP1 + OP2 rounded in the direction RND. For types
- having no signed zero, it is considered unsigned (i.e. (+0) + 0 =
- (+0) and (-0) + 0 = (-0)). The `mpfr_add_d' function assumes that
- the radix of the `double' type is a power of 2, with a precision
- at most that declared by the C implementation (macro
- `IEEE_DBL_MANT_DIG', and if not defined 53 bits).
-
- -- Function: int mpfr_sub (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_ui_sub (mpfr_t ROP, unsigned long int OP1,
- mpfr_t OP2, mp_rnd_t RND)
- -- Function: int mpfr_sub_ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_si_sub (mpfr_t ROP, long int OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_sub_si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_d_sub (mpfr_t ROP, double OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_sub_d (mpfr_t ROP, mpfr_t OP1, double OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_sub_z (mpfr_t ROP, mpfr_t OP1, mpz_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_sub_q (mpfr_t ROP, mpfr_t OP1, mpq_t OP2,
- mp_rnd_t RND)
- Set ROP to OP1 - OP2 rounded in the direction RND. For types
- having no signed zero, it is considered unsigned (i.e. (+0) - 0 =
- (+0), (-0) - 0 = (-0), 0 - (+0) = (-0) and 0 - (-0) = (+0)). The
- same restrictions than for `mpfr_add_d' apply to `mpfr_d_sub' and
- `mpfr_sub_d'.
-
- -- Function: int mpfr_mul (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_mul_ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_mul_si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_mul_d (mpfr_t ROP, mpfr_t OP1, double OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_mul_z (mpfr_t ROP, mpfr_t OP1, mpz_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_mul_q (mpfr_t ROP, mpfr_t OP1, mpq_t OP2,
- mp_rnd_t RND)
- Set ROP to OP1 times OP2 rounded in the direction RND. When a
- result is zero, its sign is the product of the signs of the
- operands (for types having no signed zero, it is considered
- positive). The same restrictions than for `mpfr_add_d' apply to
- `mpfr_mul_d'.
-
- -- Function: int mpfr_sqr (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the square of OP rounded in the direction RND.
-
- -- Function: int mpfr_div (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_ui_div (mpfr_t ROP, unsigned long int OP1,
- mpfr_t OP2, mp_rnd_t RND)
- -- Function: int mpfr_div_ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_si_div (mpfr_t ROP, long int OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_div_si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_d_div (mpfr_t ROP, double OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_div_d (mpfr_t ROP, mpfr_t OP1, double OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_div_z (mpfr_t ROP, mpfr_t OP1, mpz_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_div_q (mpfr_t ROP, mpfr_t OP1, mpq_t OP2,
- mp_rnd_t RND)
- Set ROP to OP1/OP2 rounded in the direction RND. When a result is
- zero, its sign is the product of the signs of the operands (for
- types having no signed zero, it is considered positive). The same
- restrictions than for `mpfr_add_d' apply to `mpfr_d_div' and
- `mpfr_div_d'.
-
- -- Function: int mpfr_sqrt (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_sqrt_ui (mpfr_t ROP, unsigned long int OP,
- mp_rnd_t RND)
- Set ROP to the square root of OP rounded in the direction RND.
- Return -0 if OP is -0 (to be consistent with the IEEE 754-1985
- standard). Set ROP to NaN if OP is negative.
-
- -- Function: int mpfr_rec_sqrt (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the reciprocal square root of OP rounded in the
- direction RND. Return +Inf if OP is ±0, and +0 if OP is +Inf. Set
- ROP to NaN if OP is negative.
-
- -- Function: int mpfr_cbrt (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_root (mpfr_t ROP, mpfr_t OP, unsigned long int
- K, mp_rnd_t RND)
- Set ROP to the cubic root (resp. the Kth root) of OP rounded in
- the direction RND. An odd (resp. even) root of a negative number
- (including -Inf) returns a negative number (resp. NaN). The Kth
- root of -0 is defined to be -0, whatever the parity of K.
-
- -- Function: int mpfr_pow (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_pow_ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_pow_si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_pow_z (mpfr_t ROP, mpfr_t OP1, mpz_t OP2,
- mp_rnd_t RND)
- -- Function: int mpfr_ui_pow_ui (mpfr_t ROP, unsigned long int OP1,
- unsigned long int OP2, mp_rnd_t RND)
- -- Function: int mpfr_ui_pow (mpfr_t ROP, unsigned long int OP1,
- mpfr_t OP2, mp_rnd_t RND)
- Set ROP to OP1 raised to OP2, rounded in the direction RND.
- Special values are currently handled as described in the ISO C99
- standard for the `pow' function (note this may change in future
- versions):
- * `pow(±0, Y)' returns plus or minus infinity for Y a negative
- odd integer.
-
- * `pow(±0, Y)' returns plus infinity for Y negative and not an
- odd integer.
-
- * `pow(±0, Y)' returns plus or minus zero for Y a positive odd
- integer.
-
- * `pow(±0, Y)' returns plus zero for Y positive and not an odd
- integer.
-
- * `pow(-1, ±Inf)' returns 1.
-
- * `pow(+1, Y)' returns 1 for any Y, even a NaN.
-
- * `pow(X, ±0)' returns 1 for any X, even a NaN.
-
- * `pow(X, Y)' returns NaN for finite negative X and finite
- non-integer Y.
-
- * `pow(X, -Inf)' returns plus infinity for 0 < abs(x) < 1, and
- plus zero for abs(x) > 1.
-
- * `pow(X, +Inf)' returns plus zero for 0 < abs(x) < 1, and plus
- infinity for abs(x) > 1.
-
- * `pow(-Inf, Y)' returns minus zero for Y a negative odd
- integer.
-
- * `pow(-Inf, Y)' returns plus zero for Y negative and not an
- odd integer.
-
- * `pow(-Inf, Y)' returns minus infinity for Y a positive odd
- integer.
-
- * `pow(-Inf, Y)' returns plus infinity for Y positive and not
- an odd integer.
-
- * `pow(+Inf, Y)' returns plus zero for Y negative, and plus
- infinity for Y positive.
-
- -- Function: int mpfr_neg (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to -OP rounded in the direction RND. Just changes the
- sign if ROP and OP are the same variable.
-
- -- Function: int mpfr_abs (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the absolute value of OP, rounded in the direction RND.
- Just changes the sign if ROP and OP are the same variable.
-
- -- Function: int mpfr_dim (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Set ROP to the positive difference of OP1 and OP2, i.e., OP1 - OP2
- rounded in the direction RND if OP1 > OP2, and +0 otherwise.
- Returns NaN when OP1 or OP2 is NaN.
-
- -- Function: int mpfr_mul_2ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_mul_2si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- Set ROP to OP1 times 2 raised to OP2 rounded in the direction RND.
- Just increases the exponent by OP2 when ROP and OP1 are identical.
-
- -- Function: int mpfr_div_2ui (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_div_2si (mpfr_t ROP, mpfr_t OP1, long int OP2,
- mp_rnd_t RND)
- Set ROP to OP1 divided by 2 raised to OP2 rounded in the direction
- RND. Just decreases the exponent by OP2 when ROP and OP1 are
- identical.
-
-\1f
-File: mpfr.info, Node: Comparison Functions, Next: Special Functions, Prev: Basic Arithmetic Functions, Up: MPFR Interface
-
-5.6 Comparison Functions
-========================
-
- -- Function: int mpfr_cmp (mpfr_t OP1, mpfr_t OP2)
- -- Function: int mpfr_cmp_ui (mpfr_t OP1, unsigned long int OP2)
- -- Function: int mpfr_cmp_si (mpfr_t OP1, signed long int OP2)
- -- Function: int mpfr_cmp_d (mpfr_t OP1, double OP2)
- -- Function: int mpfr_cmp_ld (mpfr_t OP1, long double OP2)
- -- Function: int mpfr_cmp_z (mpfr_t OP1, mpz_t OP2)
- -- Function: int mpfr_cmp_q (mpfr_t OP1, mpq_t OP2)
- -- Function: int mpfr_cmp_f (mpfr_t OP1, mpf_t OP2)
- Compare OP1 and OP2. Return a positive value if OP1 > OP2, zero
- if OP1 = OP2, and a negative value if OP1 < OP2. Both OP1 and OP2
- are considered to their full own precision, which may differ. If
- one of the operands is NaN, set the _erange_ flag and return zero.
-
- Note: These functions may be useful to distinguish the three
- possible cases. If you need to distinguish two cases only, it is
- recommended to use the predicate functions (e.g., `mpfr_equal_p'
- for the equality) described below; they behave like the IEEE-754
- comparisons, in particular when one or both arguments are NaN. But
- only floating-point numbers can be compared (you may need to do a
- conversion first).
-
- -- Function: int mpfr_cmp_ui_2exp (mpfr_t OP1, unsigned long int OP2,
- mp_exp_t E)
- -- Function: int mpfr_cmp_si_2exp (mpfr_t OP1, long int OP2, mp_exp_t
- E)
- Compare OP1 and OP2 multiplied by two to the power E. Similar as
- above.
-
- -- Function: int mpfr_cmpabs (mpfr_t OP1, mpfr_t OP2)
- Compare |OP1| and |OP2|. Return a positive value if |OP1| >
- |OP2|, zero if |OP1| = |OP2|, and a negative value if |OP1| <
- |OP2|. If one of the operands is NaN, set the _erange_ flag and
- return zero.
-
- -- Function: int mpfr_nan_p (mpfr_t OP)
- -- Function: int mpfr_inf_p (mpfr_t OP)
- -- Function: int mpfr_number_p (mpfr_t OP)
- -- Function: int mpfr_zero_p (mpfr_t OP)
- Return non-zero if OP is respectively NaN, an infinity, an ordinary
- number (i.e. neither NaN nor an infinity) or zero. Return zero
- otherwise.
-
- -- Macro: int mpfr_sgn (mpfr_t OP)
- Return a positive value if OP > 0, zero if OP = 0, and a negative
- value if OP < 0. If the operand is NaN, set the _erange_ flag and
- return zero.
-
- -- Function: int mpfr_greater_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 > OP2, zero otherwise.
-
- -- Function: int mpfr_greaterequal_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 >= OP2, zero otherwise.
-
- -- Function: int mpfr_less_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 < OP2, zero otherwise.
-
- -- Function: int mpfr_lessequal_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 <= OP2, zero otherwise.
-
- -- Function: int mpfr_lessgreater_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 < OP2 or OP1 > OP2 (i.e. neither OP1, nor
- OP2 is NaN, and OP1 <> OP2), zero otherwise (i.e. OP1 and/or OP2
- are NaN, or OP1 = OP2).
-
- -- Function: int mpfr_equal_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 = OP2, zero otherwise (i.e. OP1 and/or OP2
- are NaN, or OP1 <> OP2).
-
- -- Function: int mpfr_unordered_p (mpfr_t OP1, mpfr_t OP2)
- Return non-zero if OP1 or OP2 is a NaN (i.e. they cannot be
- compared), zero otherwise.
-
-\1f
-File: mpfr.info, Node: Special Functions, Next: Input and Output Functions, Prev: Comparison Functions, Up: MPFR Interface
-
-5.7 Special Functions
-=====================
-
-All those functions, except explicitly stated, return zero for an exact
-return value, a positive value for a return value larger than the exact
-result, and a negative value otherwise.
-
- Important note: in some domains, computing special functions (either
-with correct or incorrect rounding) is expensive, even for small
-precision, for example the trigonometric and Bessel functions for large
-argument.
-
- -- Function: int mpfr_log (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_log2 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_log10 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the natural logarithm of OP, log2(OP) or log10(OP),
- respectively, rounded in the direction RND. Return -Inf if OP is
- -0 (i.e. the sign of the zero has no influence on the result).
-
- -- Function: int mpfr_exp (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_exp2 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_exp10 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the exponential of OP, to 2 power of OP or to 10 power
- of OP, respectively, rounded in the direction RND.
-
- -- Function: int mpfr_cos (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_sin (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_tan (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the cosine of OP, sine of OP, tangent of OP, rounded in
- the direction RND.
-
- -- Function: int mpfr_sec (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_csc (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_cot (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the secant of OP, cosecant of OP, cotangent of OP,
- rounded in the direction RND.
-
- -- Function: int mpfr_sin_cos (mpfr_t SOP, mpfr_t COP, mpfr_t OP,
- mp_rnd_t RND)
- Set simultaneously SOP to the sine of OP and
- COP to the cosine of OP, rounded in the direction RND with the
- corresponding precisions of SOP and COP, which must be different
- variables. Return 0 iff both results are exact.
-
- -- Function: int mpfr_acos (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_asin (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_atan (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the arc-cosine, arc-sine or arc-tangent of OP, rounded
- in the direction RND. Note that since `acos(-1)' returns the
- floating-point number closest to Pi according to the given
- rounding mode, this number might not be in the output range 0 <=
- ROP < \pi of the arc-cosine function; still, the result lies in
- the image of the output range by the rounding function. The same
- holds for `asin(-1)', `asin(1)', `atan(-Inf)', `atan(+Inf)'.
-
- -- Function: int mpfr_atan2 (mpfr_t ROP, mpfr_t Y, mpfr_t X, mp_rnd_t
- RND)
- Set ROP to the arc-tangent2 of Y and X, rounded in the direction
- RND: if `x > 0', `atan2(y, x) = atan (y/x)'; if `x < 0', `atan2(y,
- x) = sign(y)*(Pi - atan (abs(y/x)))'. As for `atan', in case the
- exact mathematical result is +Pi or -Pi, its rounded result might
- be outside the function output range.
-
- `atan2(y, 0)' does not raise any floating-point exception.
- Special values are currently handled as described in the ISO C99
- standard for the `atan2' function (note this may change in future
- versions):
- * `atan2(+0, -0)' returns +Pi.
-
- * `atan2(-0, -0)' returns -Pi.
-
- * `atan2(+0, +0)' returns +0.
-
- * `atan2(-0, +0)' returns -0.
-
- * `atan2(+0, x)' returns +Pi for x < 0.
-
- * `atan2(-0, x)' returns -Pi for x < 0.
-
- * `atan2(+0, x)' returns +0 for x > 0.
-
- * `atan2(-0, x)' returns -0 for x > 0.
-
- * `atan2(y, 0)' returns -Pi/2 for y < 0.
-
- * `atan2(y, 0)' returns +Pi/2 for y > 0.
-
- * `atan2(+Inf, -Inf)' returns +3*Pi/4.
-
- * `atan2(-Inf, -Inf)' returns -3*Pi/4.
-
- * `atan2(+Inf, +Inf)' returns +Pi/4.
-
- * `atan2(-Inf, +Inf)' returns -Pi/4.
-
- * `atan2(+Inf, x)' returns +Pi/2 for finite x.
-
- * `atan2(-Inf, x)' returns -Pi/2 for finite x.
-
- * `atan2(y, -Inf)' returns +Pi for finite y > 0.
-
- * `atan2(y, -Inf)' returns -Pi for finite y < 0.
-
- * `atan2(y, +Inf)' returns +0 for finite y > 0.
-
- * `atan2(y, +Inf)' returns -0 for finite y < 0.
-
- -- Function: int mpfr_cosh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_sinh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_tanh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the hyperbolic cosine, sine or tangent of OP, rounded
- in the direction RND.
-
- -- Function: int mpfr_sinh_cosh (mpfr_t SOP, mpfr_t COP, mpfr_t OP,
- mp_rnd_t RND)
- Set simultaneously SOP to the hyperbolic sine of OP and
- COP to the hyperbolic cosine of OP, rounded in the
- direction RND with the corresponding precision of SOP and COP
- which must be different variables. Return 0 iff both results are
- exact.
-
- -- Function: int mpfr_sech (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_csch (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_coth (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the hyperbolic secant of OP, cosecant of OP, cotangent
- of OP, rounded in the direction RND.
-
- -- Function: int mpfr_acosh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_asinh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_atanh (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the inverse hyperbolic cosine, sine or tangent of OP,
- rounded in the direction RND.
-
- -- Function: int mpfr_fac_ui (mpfr_t ROP, unsigned long int OP,
- mp_rnd_t RND)
- Set ROP to the factorial of the `unsigned long int' OP, rounded in
- the direction RND.
-
- -- Function: int mpfr_log1p (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the logarithm of one plus OP, rounded in the direction
- RND.
-
- -- Function: int mpfr_expm1 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the exponential of OP minus one, rounded in the
- direction RND.
-
- -- Function: int mpfr_eint (mpfr_t Y, mpfr_t X, mp_rnd_t RND)
- Set Y to the exponential integral of X, rounded in the direction
- RND. For positive X, the exponential integral is the sum of
- Euler's constant, of the logarithm of X, and of the sum for k from
- 1 to infinity of X to the power k, divided by k and factorial(k).
- For negative X, the returned value is NaN.
-
- -- Function: int mpfr_li2 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND_MODE)
- Set ROP to real part of the dilogarithm of OP, rounded in the
- direction RND_MODE. The dilogarithm function is defined here as
- the integral of -log(1-t)/t from 0 to x.
-
- -- Function: int mpfr_gamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the Gamma function on OP, rounded in the
- direction RND. When OP is a negative integer, NaN is returned.
-
- -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the logarithm of the Gamma function on OP,
- rounded in the direction RND. When -2K-1 <= X <= -2K, K being a
- non-negative integer, NaN is returned. See also `mpfr_lgamma'.
-
- -- Function: int mpfr_lgamma (mpfr_t ROP, int *SIGNP, mpfr_t OP,
- mp_rnd_t RND)
- Set ROP to the value of the logarithm of the absolute value of the
- Gamma function on OP, rounded in the direction RND. The sign (1 or
- -1) of Gamma(OP) is returned in the object pointed to by SIGNP.
- When OP is an infinity or a non-positive integer, +Inf is
- returned. When OP is NaN, -Inf or a negative integer, *SIGNP is
- undefined, and when OP is ±0, *SIGNP is the sign of the zero.
-
- -- Function: int mpfr_zeta (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_zeta_ui (mpfr_t ROP, unsigned long OP, mp_rnd_t
- RND)
- Set ROP to the value of the Riemann Zeta function on OP, rounded
- in the direction RND.
-
- -- Function: int mpfr_erf (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the error function on OP, rounded in the
- direction RND.
-
- -- Function: int mpfr_erfc (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the complementary error function on OP,
- rounded in the direction RND.
-
- -- Function: int mpfr_j0 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_j1 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_jn (mpfr_t ROP, long N, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the first kind Bessel function of order 0,
- 1 and N on OP, rounded in the direction RND. When OP is NaN, ROP
- is always set to NaN. When OP is plus or minus Infinity, ROP is
- set to +0. When OP is zero, and N is not zero, ROP is +0 or -0
- depending on the parity and sign of N, and the sign of OP.
-
- -- Function: int mpfr_y0 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_y1 (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_yn (mpfr_t ROP, long N, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the value of the second kind Bessel function of order
- 0, 1 and N on OP, rounded in the direction RND. When OP is NaN or
- negative, ROP is always set to NaN. When OP is +Inf, ROP is +0.
- When OP is zero, ROP is +Inf or -Inf depending on the parity and
- sign of N.
-
- -- Function: int mpfr_fma (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2, mpfr_t
- OP3, mp_rnd_t RND)
- Set ROP to (OP1 times OP2) + OP3, rounded in the direction RND.
-
- -- Function: int mpfr_fms (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2, mpfr_t
- OP3, mp_rnd_t RND)
- Set ROP to (OP1 times OP2) - OP3, rounded in the direction RND.
-
- -- Function: int mpfr_agm (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Set ROP to the arithmetic-geometric mean of OP1 and OP2, rounded
- in the direction RND. The arithmetic-geometric mean is the common
- limit of the sequences u[n] and v[n], where u[0]=OP1, v[0]=OP2,
- u[n+1] is the arithmetic mean of u[n] and v[n], and v[n+1] is the
- geometric mean of u[n] and v[n]. If any operand is negative, the
- return value is NaN.
-
- -- Function: int mpfr_hypot (mpfr_t ROP, mpfr_t X, mpfr_t Y, mp_rnd_t
- RND)
- Set ROP to the Euclidean norm of X and Y, i.e. the square root of
- the sum of the squares of X and Y, rounded in the direction RND.
- Special values are currently handled as described in Section
- F.9.4.3 of the ISO C99 standard, for the `hypot' function (note
- this may change in future versions): If X or Y is an infinity,
- then plus infinity is returned in ROP, even if the other number is
- NaN.
-
- -- Function: int mpfr_const_log2 (mpfr_t ROP, mp_rnd_t RND)
- -- Function: int mpfr_const_pi (mpfr_t ROP, mp_rnd_t RND)
- -- Function: int mpfr_const_euler (mpfr_t ROP, mp_rnd_t RND)
- -- Function: int mpfr_const_catalan (mpfr_t ROP, mp_rnd_t RND)
- Set ROP to the logarithm of 2, the value of Pi, of Euler's
- constant 0.577..., of Catalan's constant 0.915..., respectively,
- rounded in the direction RND. These functions cache the computed
- values to avoid other calculations if a lower or equal precision
- is requested. To free these caches, use `mpfr_free_cache'.
-
- -- Function: void mpfr_free_cache (void)
- Free various caches used by MPFR internally, in particular the
- caches used by the functions computing constants (currently
- `mpfr_const_log2', `mpfr_const_pi', `mpfr_const_euler' and
- `mpfr_const_catalan'). You should call this function before
- terminating a thread, even if you did not call these functions
- directly (they could have been called internally).
-
- -- Function: int mpfr_sum (mpfr_t ROP, mpfr_ptr const TAB[], unsigned
- long N, mp_rnd_t RND)
- Set RET to the sum of all elements of TAB whose size is N, rounded
- in the direction RND. Warning, TAB is a table of pointers to
- mpfr_t, not a table of mpfr_t (preliminary interface). The returned
- `int' value is zero when the computed value is the exact value,
- and non-zero when this cannot be guaranteed, without giving the
- direction of the error as the other functions do.
-
-\1f
-File: mpfr.info, Node: Input and Output Functions, Next: Formatted Output Functions, Prev: Special Functions, Up: MPFR Interface
-
-5.8 Input and Output Functions
-==============================
-
-This section describes functions that perform input from an input/output
-stream, and functions that output to an input/output stream. Passing a
-null pointer for a `stream' to any of these functions will make them
-read from `stdin' and write to `stdout', respectively.
-
- When using any of these functions, you must include the `<stdio.h>'
-standard header before `mpfr.h', to allow `mpfr.h' to define prototypes
-for these functions.
-
- -- Function: size_t mpfr_out_str (FILE *STREAM, int BASE, size_t N,
- mpfr_t OP, mp_rnd_t RND)
- Output OP on stream STREAM, as a string of digits in base BASE,
- rounded in the direction RND. The base may vary from 2 to 36.
- Print N significant digits exactly, or if N is 0, enough digits so
- that OP can be read back exactly (see `mpfr_get_str').
-
- In addition to the significant digits, a decimal point (defined by
- the current locale) at the right of the first digit and a trailing
- exponent in base 10, in the form `eNNN', are printed. If BASE is
- greater than 10, `@' will be used instead of `e' as exponent
- delimiter.
-
- Return the number of bytes written, or if an error occurred,
- return 0.
-
- -- Function: size_t mpfr_inp_str (mpfr_t ROP, FILE *STREAM, int BASE,
- mp_rnd_t RND)
- Input a string in base BASE from stream STREAM, rounded in the
- direction RND, and put the read float in ROP.
-
- This function reads a word (defined as a sequence of characters
- between whitespace) and parses it using `mpfr_set_str' (it may
- change). See the documentation of `mpfr_strtofr' for a detailed
- description of the valid string formats.
-
- Return the number of bytes read, or if an error occurred, return 0.
-
-\1f
-File: mpfr.info, Node: Formatted Output Functions, Next: Integer Related Functions, Prev: Input and Output Functions, Up: MPFR Interface
-
-5.9 Formatted Output Functions
-==============================
-
-5.9.1 Requirements
-------------------
-
-The class of `mpfr_printf' functions provides formatted output in a
-similar manner as the standard C `printf'. These functions are defined
-only if your system supports ISO C variadic functions and the
-corresponding argument access macros.
-
- When using any of these functions, you must include the `<stdio.h>'
-standard header before `mpfr.h', to allow `mpfr.h' to define prototypes
-for these functions.
-
-5.9.2 Format String
--------------------
-
-The format specification accepted by `mpfr_printf' is an extension of
-the `printf' one. The conversion specification is of the form:
- % [flags] [width] [.[precision]] [type] [rounding] conv
- `flags', `width', and `precision' have the same meaning as for the
-standard C function `printf' (in particular, notice that the precision
-is related to the number of digits displayed in the base chosen by
-`conv' and not related to the internal precision of the `mpfr_t'
-variable). `mpfr_printf' accepts the same `type' specifiers as `gmp'
-(except the non-standard and deprecated `q', use `ll' instead), plus
-`R' and `P':
-
- `h' `short'
- `hh' `char'
- `j' `intmax_t' or `uintmax_t'
- `l' `long' or `wchar_t'
- `ll' `long long'
- `L' `long double'
- `t' `ptrdiff_t'
- `z' `size_t'
- `F' `mpf_t', float conversions
- `Q' `mpq_t', integer conversions
- `M' `mp_limb_t', integer conversions
- `N' `mp_limb_t' array, integer conversions
- `Z' `mpz_t', integer conversions
- `R' `mpfr_t' input, float conversions
- `P' `mpfr_prec_t' input, integer conversions
-
- The `type' specifiers have the same restrictions as those mentioned
-in the GMP documentation: *note Formatted Output Strings:
-(gmp.info)Formatted Output Strings. More precisely, except for `R' and
-`P' (which are defined by MPFR), the `type' specifiers are supported
-only if they are supported by `gmp_printf' in your GMP build; this
-implies that the standard specifiers, such as `t', must _also_ be
-supported by your C library if you want to use them.
-
- The `rounding' specifier is specific to `mpfr_t' parameter and shall
-not be used with other types. `mpfr_printf' accepts the same conversion
-specifier character `conv' as `gmp_printf' plus `b'.
-
- The `P' type outputs the precision of an `mpfr_t' variable. It is
-needed because the `mpfr_prec_t' type does not necessarily correspond
-to an `unsigned int' or any fixed standard type. For example:
- mpfr_t x;
- mpfr_prec_t p;
- mpfr_init (x);
- ...
- p = mpfr_get_prec (x);
- mpfr_printf ("variable x with %Pu bits", p);
-
- The `R' type is used for a `mpfr_t' output and can be followed by a
-rounding specifier denoted by one of the following characters:
-
- `U' round toward plus infinity
- `D' round toward minus infinity
- `Z' round toward zero
- `N' round to nearest
- `*' rounding mode (as a `mpfr_rnd_t')
- indicated by the argument just before
- the corresponding `mpfr_t' variable.
-
- If the precision field is not empty, the `mpfr_t' number is rounded
-to the given precision in the direction specified by the rounding mode.
-If the precision field is empty (as in `%.Rf'), the number is displayed
-with enough digits so that it can be read back exactly (assuming
-rounding to nearest, see `mpfr_get_str'). If no rounding is specified,
-the `mpfr_t' argument is rounded to nearest. The following three
-examples are equivalent:
- mpfr_t x;
- mpfr_init (x);
- ...
- mpfr_printf ("%.128Rf", x);
- mpfr_printf ("%.128RNf", x);
- mpfr_printf ("%.128R*f", GMP_RNDN, x);
-
- `mpfr_printf' also adds a new conversion specifier `b' which
-displays the `mpfr_t' parameter in binary, the behavior is undefined
-with other parameter type. The `conv' specifiers allowed with `mpfr_t'
-parameter are:
-
- `a' `A' hex float, C99 style
- `b' binary output
- `e' `E' scientific format float
- `f' fixed point float
- `g' `G' fixed or scientific float
-
- In case of non-decimal output, only the significand is written in the
-specified base, the exponent is always displayed in decimal. Special
-values are always displayed as `nan', `-inf', and `inf' for `a', `b',
-`e', `f', and `g' specifiers and `NAN', `-INF', and `INF' for `A', `E',
-`F', and `G' specifiers. In binary output, the precision is silently
-increased up to 2 if it equals 1.
-
-5.9.3 Functions
----------------
-
- -- Function: int mpfr_fprintf (FILE *STREAM, const char *TEMPLATE, ...)
- -- Function: int mpfr_vfprintf (FILE *STREAM, const char *TEMPLATE,
- va_list AP)
- Print to the stream STREAM the optional arguments under the
- control of the template string TEMPLATE.
-
- Return the number of characters written or a negative value if an
- error occurred. If the number of characters which ought to be
- written appears to exceed the maximum limit for an `int', nothing
- is written in the stream, the function returns -1, sets the
- _erange_ flag, and (in POSIX system only) `errno' is set to
- `EOVERFLOW'.
-
- -- Function: int mpfr_printf (const char *TEMPLATE, ...)
- -- Function: int mpfr_vprintf (const char *TEMPLATE, va_list AP)
- Print to STDOUT the optional arguments under the control of the
- template string TEMPLATE.
-
- Return the number of characters written or a negative value if an
- error occurred. If the number of characters which ought to be
- written appears to exceed the maximum limit for an `int', nothing
- is written in `stdout', the function returns -1, sets the _erange_
- flag, and (in POSIX system only) `errno' is set to `EOVERFLOW'.
-
- -- Function: int mpfr_sprintf (char *BUF, const char *TEMPLATE, ...)
- -- Function: int mpfr_vsprintf (char *BUF, const char *TEMPLATE,
- va_list AP)
- Form a null-terminated string in BUF. No overlap is permitted
- between BUF and the other arguments.
-
- Return the number of characters written in the array BUF not
- counting the terminating null character or a negative value if an
- error occurred. If the number of characters which ought to be
- written appears to exceed the maximum limit for an `int', nothing
- is written in BUF, the function returns -1, sets the _erange_
- flag, and (in POSIX system only) `errno' is set to `EOVERFLOW'.
-
- -- Function: int mpfr_snprintf (char *BUF, size_t N, const char
- *TEMPLATE, ...)
- -- Function: int mpfr_vsnprintf (char *BUF, size_t N, const char
- *TEMPLATE, va_list AP)
- Form a null-terminated string in BUF. If N is zero, nothing is
- written and BUF may be a null pointer, otherwise, the `n-1' first
- characters are written in BUF and the N-th is a null character.
-
- Return the number of characters that would have been written had N
- be sufficiently large, not counting the terminating null character
- or a negative value if an error occurred. If the number of
- characters produced by the optional arguments under the control of
- the template string TEMPLATE appears to exceed the maximum limit
- for an `int', nothing is written in BUF, the function returns -1,
- sets the _erange_ flag, and (in POSIX system only) `errno' is set
- to `EOVERFLOW'.
-
- -- Function: int mpfr_asprintf (char **STR, const char *TEMPLATE, ...)
- -- Function: int mpfr_vasprintf (char **STR, const char *TEMPLATE,
- va_list AP)
- Write their output as a null terminated string in a block of
- memory allocated using the current allocation function. A pointer
- to the block is stored in STR. The block of memory must be freed
- using `mpfr_free_str'.
-
- The return value is the number of characters written in the
- string, excluding the null-terminator or a negative value if an
- error occurred. If the number of characters produced by the
- optional arguments under the control of the template string
- TEMPLATE appears to exceed the maximum limit for an `int', STR is
- a null pointer, the function returns -1, sets the _erange_ flag,
- and (in POSIX system only) `errno' is set to `EOVERFLOW'.
-
-\1f
-File: mpfr.info, Node: Integer Related Functions, Next: Rounding Related Functions, Prev: Formatted Output Functions, Up: MPFR Interface
-
-5.10 Integer and Remainder Related Functions
-============================================
-
- -- Function: int mpfr_rint (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_ceil (mpfr_t ROP, mpfr_t OP)
- -- Function: int mpfr_floor (mpfr_t ROP, mpfr_t OP)
- -- Function: int mpfr_round (mpfr_t ROP, mpfr_t OP)
- -- Function: int mpfr_trunc (mpfr_t ROP, mpfr_t OP)
- Set ROP to OP rounded to an integer. `mpfr_rint' rounds to the
- nearest representable integer in the given rounding mode,
- `mpfr_ceil' rounds to the next higher or equal representable
- integer, `mpfr_floor' to the next lower or equal representable
- integer, `mpfr_round' to the nearest representable integer,
- rounding halfway cases away from zero, and `mpfr_trunc' to the
- next representable integer toward zero.
-
- The returned value is zero when the result is exact, positive when
- it is greater than the original value of OP, and negative when it
- is smaller. More precisely, the returned value is 0 when OP is an
- integer representable in ROP, 1 or -1 when OP is an integer that
- is not representable in ROP, 2 or -2 when OP is not an integer.
-
- Note that `mpfr_round' is different from `mpfr_rint' called with
- the rounding to nearest mode (where halfway cases are rounded to
- an even integer or significand). Note also that no double rounding
- is performed; for instance, 4.5 (100.1 in binary) is rounded by
- `mpfr_round' to 4 (100 in binary) in 2-bit precision, though
- `round(4.5)' is equal to 5 and 5 (101 in binary) is rounded to 6
- (110 in binary) in 2-bit precision.
-
- -- Function: int mpfr_rint_ceil (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_rint_floor (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_rint_round (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- -- Function: int mpfr_rint_trunc (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to OP rounded to an integer. `mpfr_rint_ceil' rounds to
- the next higher or equal integer, `mpfr_rint_floor' to the next
- lower or equal integer, `mpfr_rint_round' to the nearest integer,
- rounding halfway cases away from zero, and `mpfr_rint_trunc' to
- the next integer toward zero. If the result is not representable,
- it is rounded in the direction RND. The returned value is the
- ternary value associated with the considered round-to-integer
- function (regarded in the same way as any other mathematical
- function).
-
- -- Function: int mpfr_frac (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
- Set ROP to the fractional part of OP, having the same sign as OP,
- rounded in the direction RND (unlike in `mpfr_rint', RND affects
- only how the exact fractional part is rounded, not how the
- fractional part is generated).
-
- -- Function: int mpfr_modf (mpfr_t IOP, mpfr_t FOP, mpfr_t OP,
- mp_rnd_t RND)
- Set simultaneously IOP to the integral part of OP and FOP to the
- fractional part of OP, rounded in the direction RND with the
- corresponding precision of IOP and FOP (equivalent to
- `mpfr_trunc(IOP, OP, RND)' and `mpfr_frac(FOP, OP, RND)'). The
- variables IOP and FOP must be different. Return 0 iff both results
- are exact.
-
- -- Function: int mpfr_fmod (mpfr_t R, mpfr_t X, mpfr_t Y, mp_rnd_t RND)
- -- Function: int mpfr_remainder (mpfr_t R, mpfr_t X, mpfr_t Y,
- mp_rnd_t RND)
- -- Function: int mpfr_remquo (mpfr_t R, long* Q, mpfr_t X, mpfr_t Y,
- mp_rnd_t RND)
- Set R to the value of x - n y, rounded according to the direction
- RND, where n is the integer quotient of X divided by Y, defined as
- follows: n is rounded toward zero for `mpfr_fmod', and to the
- nearest integer (ties rounded to even) for `mpfr_remainder' and
- `mpfr_remquo'.
-
- Special values are handled as described in Section F.9.7.1 of the
- ISO C99 standard: If X is infinite or Y is zero, R is NaN. If Y
- is infinite and X is finite, R is X rounded to the precision of R.
- If R is zero, it has the sign of X. The return value is the
- ternary value corresponding to R.
-
- Additionally, `mpfr_remquo' stores the low significant bits from
- the quotient in *Q (more precisely the number of bits in a `long'
- minus one), with the sign of X divided by Y (except if those low
- bits are all zero, in which case zero is returned). Note that X
- may be so large in magnitude relative to Y that an exact
- representation of the quotient is not practical. `mpfr_remainder'
- and `mpfr_remquo' functions are useful for additive argument
- reduction.
-
- -- Function: int mpfr_integer_p (mpfr_t OP)
- Return non-zero iff OP is an integer.
-
-\1f
-File: mpfr.info, Node: Rounding Related Functions, Next: Miscellaneous Functions, Prev: Integer Related Functions, Up: MPFR Interface
-
-5.11 Rounding Related Functions
-===============================
-
- -- Function: void mpfr_set_default_rounding_mode (mp_rnd_t RND)
- Set the default rounding mode to RND. The default rounding mode
- is to nearest initially.
-
- -- Function: mp_rnd_t mpfr_get_default_rounding_mode (void)
- Get the default rounding mode.
-
- -- Function: int mpfr_prec_round (mpfr_t X, mp_prec_t PREC, mp_rnd_t
- RND)
- Round X according to RND with precision PREC, which must be an
- integer between `MPFR_PREC_MIN' and `MPFR_PREC_MAX' (otherwise the
- behavior is undefined). If PREC is greater or equal to the
- precision of X, then new space is allocated for the significand,
- and it is filled with zeros. Otherwise, the significand is
- rounded to precision PREC with the given direction. In both cases,
- the precision of X is changed to PREC.
-
- -- Function: int mpfr_round_prec (mpfr_t X, mp_rnd_t RND, mp_prec_t
- PREC)
- [This function is obsolete. Please use `mpfr_prec_round' instead.]
-
- -- Function: int mpfr_can_round (mpfr_t B, mp_exp_t ERR, mp_rnd_t
- RND1, mp_rnd_t RND2, mp_prec_t PREC)
- Assuming B is an approximation of an unknown number X in the
- direction RND1 with error at most two to the power E(b)-ERR where
- E(b) is the exponent of B, return a non-zero value if one is able
- to round correctly X to precision PREC with the direction RND2,
- and 0 otherwise (including for NaN and Inf). This function *does
- not modify* its arguments.
-
- Note: if one wants to also determine the correct ternary value
- when rounding B to precision PREC, a useful trick is the following: if (mpfr_can_round (b, err, rnd1, GMP_RNDZ, prec + (rnd2 == GMP_RNDN)))
- ...
- Indeed, if RND2 is `GMP_RNDN', this will check if one can round
- to PREC+1 bits with a directed rounding: if so, one can surely
- round to nearest to PREC bits, and in addition one can determine
- the correct ternary value, which would not be the case when B is
- near from a value exactly representable on PREC bits.
-
- -- Function: const char * mpfr_print_rnd_mode (mp_rnd_t RND)
- Return the input string (GMP_RNDD, GMP_RNDU, GMP_RNDN, GMP_RNDZ)
- corresponding to the rounding mode RND or a null pointer if RND is
- an invalid rounding mode.
-
-\1f
-File: mpfr.info, Node: Miscellaneous Functions, Next: Exception Related Functions, Prev: Rounding Related Functions, Up: MPFR Interface
-
-5.12 Miscellaneous Functions
-============================
-
- -- Function: void mpfr_nexttoward (mpfr_t X, mpfr_t Y)
- If X or Y is NaN, set X to NaN. Otherwise, if X is different from
- Y, replace X by the next floating-point number (with the precision
- of X and the current exponent range) in the direction of Y, if
- there is one (the infinite values are seen as the smallest and
- largest floating-point numbers). If the result is zero, it keeps
- the same sign. No underflow or overflow is generated.
-
- -- Function: void mpfr_nextabove (mpfr_t X)
- Equivalent to `mpfr_nexttoward' where Y is plus infinity.
-
- -- Function: void mpfr_nextbelow (mpfr_t X)
- Equivalent to `mpfr_nexttoward' where Y is minus infinity.
-
- -- Function: int mpfr_min (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Set ROP to the minimum of OP1 and OP2. If OP1 and OP2 are both
- NaN, then ROP is set to NaN. If OP1 or OP2 is NaN, then ROP is set
- to the numeric value. If OP1 and OP2 are zeros of different signs,
- then ROP is set to -0.
-
- -- Function: int mpfr_max (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Set ROP to the maximum of OP1 and OP2. If OP1 and OP2 are both
- NaN, then ROP is set to NaN. If OP1 or OP2 is NaN, then ROP is set
- to the numeric value. If OP1 and OP2 are zeros of different signs,
- then ROP is set to +0.
-
- -- Function: int mpfr_urandomb (mpfr_t ROP, gmp_randstate_t STATE)
- Generate a uniformly distributed random float in the interval 0 <=
- ROP < 1. More precisely, the number can be seen as a float with a
- random non-normalized significand and exponent 0, which is then
- normalized (thus if E denotes the exponent after normalization,
- then the least -E significant bits of the significand are always
- 0). Return 0, unless the exponent is not in the current exponent
- range, in which case ROP is set to NaN and a non-zero value is
- returned (this should never happen in practice, except in very
- specific cases). The second argument is a `gmp_randstate_t'
- structure which should be created using the GMP `gmp_randinit'
- function, see the GMP manual.
-
- -- Function: void mpfr_random (mpfr_t ROP)
- Generate a uniformly distributed random float in the interval 0 <=
- ROP < 1.
-
- This function is deprecated and will be suppressed in the next
- release; `mpfr_urandomb' should be used instead.
-
- -- Function: void mpfr_random2 (mpfr_t ROP, mp_size_t SIZE, mp_exp_t
- EXP)
- Generate a random float of at most SIZE limbs, with long strings of
- zeros and ones in the binary representation. The exponent of the
- number is in the interval -EXP to EXP. This function is useful for
- testing functions and algorithms, since this kind of random
- numbers have proven to be more likely to trigger corner-case bugs.
- Negative random numbers are generated when SIZE is negative. Put
- +0 in ROP when size if zero. The internal state of the default
- pseudorandom number generator is modified by a call to this
- function (the same one as GMP if MPFR was built using
- `--with-gmp-build').
-
- This function is deprecated and will be suppressed in the next
- release.
-
- -- Function: mp_exp_t mpfr_get_exp (mpfr_t X)
- Get the exponent of X, assuming that X is a non-zero ordinary
- number and the significand is chosen in [1/2,1). The behavior for
- NaN, infinity or zero is undefined.
-
- -- Function: int mpfr_set_exp (mpfr_t X, mp_exp_t E)
- Set the exponent of X if E is in the current exponent range, and
- return 0 (even if X is not a non-zero ordinary number); otherwise,
- return a non-zero value. The significand is assumed to be in
- [1/2,1).
-
- -- Function: int mpfr_signbit (mpfr_t OP)
- Return a non-zero value iff OP has its sign bit set (i.e. if it is
- negative, -0, or a NaN whose representation has its sign bit set).
-
- -- Function: int mpfr_setsign (mpfr_t ROP, mpfr_t OP, int S, mp_rnd_t
- RND)
- Set the value of ROP from OP, rounded toward the given direction
- RND, then set (resp. clear) its sign bit if S is non-zero (resp.
- zero), even when OP is a NaN.
-
- -- Function: int mpfr_copysign (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Set the value of ROP from OP1, rounded toward the given direction
- RND, then set its sign bit to that of OP2 (even when OP1 or OP2 is
- a NaN). This function is equivalent to `mpfr_setsign (ROP, OP1,
- mpfr_signbit (OP2), RND)'.
-
- -- Function: const char * mpfr_get_version (void)
- Return the MPFR version, as a null-terminated string.
-
- -- Macro: MPFR_VERSION
- -- Macro: MPFR_VERSION_MAJOR
- -- Macro: MPFR_VERSION_MINOR
- -- Macro: MPFR_VERSION_PATCHLEVEL
- -- Macro: MPFR_VERSION_STRING
- `MPFR_VERSION' is the version of MPFR as a preprocessing constant.
- `MPFR_VERSION_MAJOR', `MPFR_VERSION_MINOR' and
- `MPFR_VERSION_PATCHLEVEL' are respectively the major, minor and
- patch level of MPFR version, as preprocessing constants.
- `MPFR_VERSION_STRING' is the version (with an optional suffix, used
- in development and pre-release versions) as a string constant,
- which can be compared to the result of `mpfr_get_version' to check
- at run time the header file and library used match:
- if (strcmp (mpfr_get_version (), MPFR_VERSION_STRING))
- fprintf (stderr, "Warning: header and library do not match\n");
- Note: Obtaining different strings is not necessarily an error, as
- in general, a program compiled with some old MPFR version can be
- dynamically linked with a newer MPFR library version (if allowed
- by the library versioning system).
-
- -- Macro: long MPFR_VERSION_NUM (MAJOR, MINOR, PATCHLEVEL)
- Create an integer in the same format as used by `MPFR_VERSION'
- from the given MAJOR, MINOR and PATCHLEVEL. Here is an example of
- how to check the MPFR version at compile time:
- #if (!defined(MPFR_VERSION) || (MPFR_VERSION<MPFR_VERSION_NUM(2,1,0)))
- # error "Wrong MPFR version."
- #endif
-
- -- Function: const char * mpfr_get_patches (void)
- Return a null-terminated string containing the ids of the patches
- applied to the MPFR library (contents of the `PATCHES' file),
- separated by spaces. Note: If the program has been compiled with
- an older MPFR version and is dynamically linked with a new MPFR
- library version, the ids of the patches applied to the old
- (compile-time) MPFR version are not available (however this
- information should not have much interest in general).
-
-\1f
-File: mpfr.info, Node: Exception Related Functions, Next: Compatibility with MPF, Prev: Miscellaneous Functions, Up: MPFR Interface
-
-5.13 Exception Related Functions
-================================
-
- -- Function: mp_exp_t mpfr_get_emin (void)
- -- Function: mp_exp_t mpfr_get_emax (void)
- Return the (current) smallest and largest exponents allowed for a
- floating-point variable. The smallest positive value of a
- floating-point variable is one half times 2 raised to the smallest
- exponent and the largest value has the form (1 - epsilon) times 2
- raised to the largest exponent.
-
- -- Function: int mpfr_set_emin (mp_exp_t EXP)
- -- Function: int mpfr_set_emax (mp_exp_t EXP)
- Set the smallest and largest exponents allowed for a
- floating-point variable. Return a non-zero value when EXP is not
- in the range accepted by the implementation (in that case the
- smallest or largest exponent is not changed), and zero otherwise.
- If the user changes the exponent range, it is her/his
- responsibility to check that all current floating-point variables
- are in the new allowed range (for example using
- `mpfr_check_range'), otherwise the subsequent behavior will be
- undefined, in the sense of the ISO C standard.
-
- -- Function: mp_exp_t mpfr_get_emin_min (void)
- -- Function: mp_exp_t mpfr_get_emin_max (void)
- -- Function: mp_exp_t mpfr_get_emax_min (void)
- -- Function: mp_exp_t mpfr_get_emax_max (void)
- Return the minimum and maximum of the smallest and largest
- exponents allowed for `mpfr_set_emin' and `mpfr_set_emax'. These
- values are implementation dependent; it is possible to create a non
- portable program by writing `mpfr_set_emax(mpfr_get_emax_max())'
- and `mpfr_set_emin(mpfr_get_emin_min())' since the values of the
- smallest and largest exponents become implementation dependent.
-
- -- Function: int mpfr_check_range (mpfr_t X, int T, mp_rnd_t RND)
- This function forces X to be in the current range of acceptable
- values, T being the current ternary value: negative if X is
- smaller than the exact value, positive if X is larger than the
- exact value and zero if X is exact (before the call). It generates
- an underflow or an overflow if the exponent of X is outside the
- current allowed range; the value of T may be used to avoid a
- double rounding. This function returns zero if the rounded result
- is equal to the exact one, a positive value if the rounded result
- is larger than the exact one, a negative value if the rounded
- result is smaller than the exact one. Note that unlike most
- functions, the result is compared to the exact one, not the input
- value X, i.e. the ternary value is propagated.
-
- Note: If X is an infinity and T is different from zero (i.e., if
- the rounded result is an inexact infinity), then the overflow flag
- is set. This is useful because `mpfr_check_range' is typically
- called (at least in MPFR functions) after restoring the flags that
- could have been set due to internal computations.
-
- -- Function: int mpfr_subnormalize (mpfr_t X, int T, mp_rnd_t RND)
- This function rounds X emulating subnormal number arithmetic: if X
- is outside the subnormal exponent range, it just propagates the
- ternary value T; otherwise, it rounds X to precision
- `EXP(x)-emin+1' according to rounding mode RND and previous
- ternary value T, avoiding double rounding problems. More
- precisely in the subnormal domain, denoting by E the value of
- `emin', X is rounded in fixed-point arithmetic to an integer
- multiple of two to the power E-1; as a consequence, 1.5 multiplied
- by two to the power E-1 when T is zero is rounded to two to the
- power E with rounding to nearest.
-
- `PREC(x)' is not modified by this function. RND and T must be the
- used rounding mode for computing X and the returned ternary value
- when computing X. The subnormal exponent range is from `emin' to
- `emin+PREC(x)-1'. If the result cannot be represented in the
- current exponent range (due to a too small `emax'), the behavior
- is undefined. Note that unlike most functions, the result is
- compared to the exact one, not the input value X, i.e. the ternary
- value is propagated. This is a preliminary interface.
-
- This is an example of how to emulate double IEEE-754 arithmetic
-using MPFR:
-
- {
- mpfr_t xa, xb;
- int i;
- volatile double a, b;
-
- mpfr_set_default_prec (53);
- mpfr_set_emin (-1073);
- mpfr_set_emax (1024);
-
- mpfr_init (xa); mpfr_init (xb);
-
- b = 34.3; mpfr_set_d (xb, b, GMP_RNDN);
- a = 0x1.1235P-1021; mpfr_set_d (xa, a, GMP_RNDN);
-
- a /= b;
- i = mpfr_div (xa, xa, xb, GMP_RNDN);
- i = mpfr_subnormalize (xa, i, GMP_RNDN);
-
- mpfr_clear (xa); mpfr_clear (xb);
- }
-
- Warning: this emulates a double IEEE-754 arithmetic with correct
-rounding in the subnormal range, which may not be the case for your
-hardware.
-
- -- Function: void mpfr_clear_underflow (void)
- -- Function: void mpfr_clear_overflow (void)
- -- Function: void mpfr_clear_nanflag (void)
- -- Function: void mpfr_clear_inexflag (void)
- -- Function: void mpfr_clear_erangeflag (void)
- Clear the underflow, overflow, invalid, inexact and _erange_ flags.
-
- -- Function: void mpfr_set_underflow (void)
- -- Function: void mpfr_set_overflow (void)
- -- Function: void mpfr_set_nanflag (void)
- -- Function: void mpfr_set_inexflag (void)
- -- Function: void mpfr_set_erangeflag (void)
- Set the underflow, overflow, invalid, inexact and _erange_ flags.
-
- -- Function: void mpfr_clear_flags (void)
- Clear all global flags (underflow, overflow, inexact, invalid,
- _erange_).
-
- -- Function: int mpfr_underflow_p (void)
- -- Function: int mpfr_overflow_p (void)
- -- Function: int mpfr_nanflag_p (void)
- -- Function: int mpfr_inexflag_p (void)
- -- Function: int mpfr_erangeflag_p (void)
- Return the corresponding (underflow, overflow, invalid, inexact,
- _erange_) flag, which is non-zero iff the flag is set.
-
-\1f
-File: mpfr.info, Node: Compatibility with MPF, Next: Custom Interface, Prev: Exception Related Functions, Up: MPFR Interface
-
-5.14 Compatibility With MPF
-===========================
-
-A header file `mpf2mpfr.h' is included in the distribution of MPFR for
-compatibility with the GNU MP class MPF. After inserting the following
-two lines after the `#include <gmp.h>' line,
-#include <mpfr.h>
-#include <mpf2mpfr.h>
- any program written for MPF can be compiled directly with MPFR without
-any changes. All operations are then performed with the default MPFR
-rounding mode, which can be reset with `mpfr_set_default_rounding_mode'.
-
- Warning: the `mpf_init' and `mpf_init2' functions initialize to
-zero, whereas the corresponding MPFR functions initialize to NaN: this
-is useful to detect uninitialized values, but is slightly incompatible
-with `mpf'.
-
- -- Function: void mpfr_set_prec_raw (mpfr_t X, mp_prec_t PREC)
- Reset the precision of X to be *exactly* PREC bits. The only
- difference with `mpfr_set_prec' is that PREC is assumed to be
- small enough so that the significand fits into the current
- allocated memory space for X. Otherwise the behavior is undefined.
-
- -- Function: int mpfr_eq (mpfr_t OP1, mpfr_t OP2, unsigned long int
- OP3)
- Return non-zero if OP1 and OP2 are both non-zero ordinary numbers
- with the same exponent and the same first OP3 bits, both zero, or
- both infinities of the same sign. Return zero otherwise. This
- function is defined for compatibility with `mpf'. Do not use it if
- you want to know whether two numbers are close to each other; for
- instance, 1.011111 and 1.100000 are currently regarded as
- different for any value of OP3 larger than 1 (but this may change
- in the next release).
-
- -- Function: void mpfr_reldiff (mpfr_t ROP, mpfr_t OP1, mpfr_t OP2,
- mp_rnd_t RND)
- Compute the relative difference between OP1 and OP2 and store the
- result in ROP. This function does not guarantee the correct
- rounding on the relative difference; it just computes
- |OP1-OP2|/OP1, using the rounding mode RND for all operations and
- the precision of ROP.
-
- -- Function: int mpfr_mul_2exp (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- -- Function: int mpfr_div_2exp (mpfr_t ROP, mpfr_t OP1, unsigned long
- int OP2, mp_rnd_t RND)
- See `mpfr_mul_2ui' and `mpfr_div_2ui'. These functions are only
- kept for compatibility with MPF.
-
-\1f
-File: mpfr.info, Node: Custom Interface, Next: Internals, Prev: Compatibility with MPF, Up: MPFR Interface
-
-5.15 Custom Interface
-=====================
-
-Some applications use a stack to handle the memory and their objects.
-However, the MPFR memory design is not well suited for such a thing. So
-that such applications are able to use MPFR, an auxiliary memory
-interface has been created: the Custom Interface.
-
- The following interface allows them to use MPFR in two ways:
- * Either they directly store the MPFR FP number as a `mpfr_t' on the
- stack.
-
- * Either they store their own representation of a FP number on the
- stack and construct a new temporary `mpfr_t' each time it is
- needed.
- Nothing has to be done to destroy the FP numbers except garbaging
-the used memory: all the memory stuff (allocating, destroying,
-garbaging) is kept to the application.
-
- Each function in this interface is also implemented as a macro for
-efficiency reasons: for example `mpfr_custom_init (s, p)' uses the
-macro, while `(mpfr_custom_init) (s, p)' uses the function.
-
- Note 1: MPFR functions may still initialize temporary FP numbers
-using standard mpfr_init. See Custom Allocation (GNU MP).
-
- Note 2: MPFR functions may use the cached functions (mpfr_const_pi
-for example), even if they are not explicitly called. You have to call
-`mpfr_free_cache' each time you garbage the memory iff mpfr_init,
-through GMP Custom Allocation, allocates its memory on the application
-stack.
-
- Note 3: This interface is preliminary.
-
- -- Function: size_t mpfr_custom_get_size (mp_prec_t PREC)
- Return the needed size in bytes to store the significand of a FP
- number of precision PREC.
-
- -- Function: void mpfr_custom_init (void *SIGNIFICAND, mp_prec_t PREC)
- Initialize a significand of precision PREC. SIGNIFICAND must be
- an area of `mpfr_custom_get_size (prec)' bytes at least and be
- suitably aligned for an array of `mp_limb_t'.
-
- -- Function: void mpfr_custom_init_set (mpfr_t X, int KIND, mp_exp_t
- EXP, mp_prec_t PREC, void *SIGNIFICAND)
- Perform a dummy initialization of a `mpfr_t' and set it to:
- * if `ABS(kind) == MPFR_NAN_KIND', X is set to NaN;
-
- * if `ABS(kind) == MPFR_INF_KIND', X is set to the infinity of
- sign `sign(kind)';
-
- * if `ABS(kind) == MPFR_ZERO_KIND', X is set to the zero of
- sign `sign(kind)';
-
- * if `ABS(kind) == MPFR_REGULAR_KIND', X is set to a regular
- number: `x = sign(kind)*significand*2^exp'
- In all cases, it uses SIGNIFICAND directly for further computing
- involving X. It will not allocate anything. A FP number
- initialized with this function cannot be resized using
- `mpfr_set_prec', or cleared using `mpfr_clear'! SIGNIFICAND must
- have been initialized with `mpfr_custom_init' using the same
- precision PREC.
-
- -- Function: int mpfr_custom_get_kind (mpfr_t X)
- Return the current kind of a `mpfr_t' as used by
- `mpfr_custom_init_set'. The behavior of this function for any
- `mpfr_t' not initialized with `mpfr_custom_init_set' is undefined.
-
- -- Function: void * mpfr_custom_get_mantissa (mpfr_t X)
- Return a pointer to the significand used by a `mpfr_t' initialized
- with `mpfr_custom_init_set'. The behavior of this function for
- any `mpfr_t' not initialized with `mpfr_custom_init_set' is
- undefined.
-
- -- Function: mp_exp_t mpfr_custom_get_exp (mpfr_t X)
- Return the exponent of X, assuming that X is a non-zero ordinary
- number. The return value for NaN, Infinity or Zero is unspecified
- but does not produce any trap. The behavior of this function for
- any `mpfr_t' not initialized with `mpfr_custom_init_set' is
- undefined.
-
- -- Function: void mpfr_custom_move (mpfr_t X, void *NEW_POSITION)
- Inform MPFR that the significand has moved due to a garbage collect
- and update its new position to `new_position'. However the
- application has to move the significand and the `mpfr_t' itself.
- The behavior of this function for any `mpfr_t' not initialized
- with `mpfr_custom_init_set' is undefined.
-
- See the test suite for examples.
-
-\1f
-File: mpfr.info, Node: Internals, Prev: Custom Interface, Up: MPFR Interface
-
-5.16 Internals
-==============
-
-The following types and functions were mainly designed for the
-implementation of MPFR, but may be useful for users too. However no
-upward compatibility is guaranteed. You may need to include
-`mpfr-impl.h' to use them.
-
- The `mpfr_t' type consists of four fields.
-
- * The `_mpfr_prec' field is used to store the precision of the
- variable (in bits); this is not less than `MPFR_PREC_MIN'.
-
- * The `_mpfr_sign' field is used to store the sign of the variable.
-
- * The `_mpfr_exp' field stores the exponent. An exponent of 0 means
- a radix point just above the most significant limb. Non-zero
- values n are a multiplier 2^n relative to that point. A NaN, an
- infinity and a zero are indicated by a special value of the
- exponent.
-
- * Finally, the `_mpfr_d' is a pointer to the limbs, least
- significant limbs stored first. The number of limbs in use is
- controlled by `_mpfr_prec', namely
- ceil(`_mpfr_prec'/`mp_bits_per_limb'). Non-singular values always
- have the most significant bit of the most significant limb set to
- 1. When the precision does not correspond to a whole number of
- limbs, the excess bits at the low end of the data are zero.
-
-
-\1f
-File: mpfr.info, Node: Contributors, Next: References, Prev: MPFR Interface, Up: Top
-
-Contributors
-************
-
-The main developers of MPFR are Guillaume Hanrot, Vincent Lefèvre,
-Patrick Pélissier, Philippe Théveny and Paul Zimmermann.
-
- Sylvie Boldo from ENS-Lyon, France, contributed the functions
-`mpfr_agm' and `mpfr_log'. Emmanuel Jeandel, from ENS-Lyon too,
-contributed the generic hypergeometric code, as well as the `mpfr_exp3',
-a first implementation of the sine and cosine, and improved versions of
-`mpfr_const_log2' and `mpfr_const_pi'. Mathieu Dutour contributed the
-functions `mpfr_atan' and `mpfr_asin', and a previous version of
-`mpfr_gamma'; David Daney contributed the hyperbolic and inverse
-hyperbolic functions, the base-2 exponential, and the factorial
-function. Fabrice Rouillier contributed the original version of
-`mul_ui.c', the `gmp_op.c' file, and helped to the Microsoft Windows
-porting. Jean-Luc Rémy contributed the `mpfr_zeta' code. Ludovic
-Meunier helped in the design of the `mpfr_erf' code. Damien Stehlé
-contributed the `mpfr_get_ld_2exp' function.
-
- We would like to thank Jean-Michel Muller and Joris van der Hoeven
-for very fruitful discussions at the beginning of that project,
-Torbjörn Granlund and Kevin Ryde for their help about design issues,
-and Nathalie Revol for her careful reading of a previous version of
-this documentation. Kevin Ryde did a tremendous job for the
-portability of MPFR in 2002-2004.
-
- The development of the MPFR library would not have been possible
-without the continuous support of INRIA, and of the LORIA (Nancy,
-France) and LIP (Lyon, France) laboratories. In particular the main
-authors were or are members of the PolKA, Spaces, Cacao project-teams
-at LORIA and of the Arenaire project-team at LIP. This project was
-started during the Fiable (reliable in French) action supported by
-INRIA, and continued during the AOC action. The development of MPFR
-was also supported by a grant (202F0659 00 MPN 121) from the Conseil
-Régional de Lorraine in 2002, and from INRIA by an "associate engineer"
-grant (2003-2005) and an "opération de développement logiciel" grant
-(2007-2009).
-
-\1f
-File: mpfr.info, Node: References, Next: GNU Free Documentation License, Prev: Contributors, Up: Top
-
-References
-**********
-
- * Laurent Fousse, Guillaume Hanrot, Vincent Lefèvre, Patrick
- Pélissier and Paul Zimmermann, "MPFR: A Multiple-Precision Binary
- Floating-Point Library With Correct Rounding", ACM Transactions on
- Mathematical Software, volume 33, issue 2, article 13, 15 pages,
- 2007, `http://doi.acm.org/10.1145/1236463.1236468'.
-
- * Torbjörn Granlund, "GNU MP: The GNU Multiple Precision Arithmetic
- Library", version 4.2.2, 2007, `http://gmplib.org'.
-
- * IEEE standard for binary floating-point arithmetic, Technical
- Report ANSI-IEEE Standard 754-1985, New York, 1985. Approved
- March 21, 1985: IEEE Standards Board; approved July 26, 1985:
- American National Standards Institute, 18 pages.
-
- * Donald E. Knuth, "The Art of Computer Programming", vol 2,
- "Seminumerical Algorithms", 2nd edition, Addison-Wesley, 1981.
-
- * Jean-Michel Muller, "Elementary Functions, Algorithms and
- Implementation", Birkhauser, Boston, 2nd edition, 2006.
-
-
-\1f
-File: mpfr.info, Node: GNU Free Documentation License, Next: Concept Index, Prev: References, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.2, November 2002
-
- Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
- 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
-
- 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.
-
- 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 for under this License. Any other
- attempt to copy, modify, sublicense or distribute the Document is
- void, and will automatically terminate your rights under this
- License. However, parties who have received copies, or rights,
- from you under this License will not have their licenses
- terminated so long as such parties remain in full compliance.
-
- 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.
-
-A.1 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.2
- 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.
-
-\1f
-File: mpfr.info, Node: Concept Index, Next: Function Index, Prev: GNU Free Documentation License, Up: Top
-
-Concept Index
-*************
-
-\0\b[index\0\b]
-* Menu:
-
-* Accuracy: MPFR Interface. (line 28)
-* Arithmetic functions: Basic Arithmetic Functions.
- (line 3)
-* Assignment functions: Assignment Functions. (line 3)
-* Basic arithmetic functions: Basic Arithmetic Functions.
- (line 3)
-* Combined initialization and assignment functions: Combined Initialization and Assignment Functions.
- (line 3)
-* Comparison functions: Comparison Functions. (line 3)
-* Compatibility with MPF: Compatibility with MPF.
- (line 3)
-* Conditions for copying MPFR: Copying. (line 6)
-* Conversion functions: Conversion Functions. (line 3)
-* Copying conditions: Copying. (line 6)
-* Custom interface: Custom Interface. (line 3)
-* Exception related functions: Exception Related Functions.
- (line 3)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* Float arithmetic functions: Basic Arithmetic Functions.
- (line 3)
-* Float comparisons functions: Comparison Functions. (line 3)
-* Float functions: MPFR Interface. (line 6)
-* Float input and output functions: Input and Output Functions.
- (line 3)
-* Float output functions: Formatted Output Functions.
- (line 3)
-* Floating-point functions: MPFR Interface. (line 6)
-* Floating-point number: MPFR Basics. (line 52)
-* GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* I/O functions <1>: Formatted Output Functions.
- (line 3)
-* I/O functions: Input and Output Functions.
- (line 3)
-* Initialization functions: Initialization Functions.
- (line 3)
-* Input functions: Input and Output Functions.
- (line 3)
-* Installation: Installing MPFR. (line 6)
-* Integer related functions: Integer Related Functions.
- (line 3)
-* Internals: Internals. (line 3)
-* libmpfr: MPFR Basics. (line 32)
-* Libraries: MPFR Basics. (line 32)
-* Libtool: MPFR Basics. (line 38)
-* Limb: MPFR Basics. (line 84)
-* Linking: MPFR Basics. (line 32)
-* Miscellaneous float functions: Miscellaneous Functions.
- (line 3)
-* mpfr.h: MPFR Basics. (line 9)
-* Output functions <1>: Formatted Output Functions.
- (line 3)
-* Output functions: Input and Output Functions.
- (line 3)
-* Precision <1>: MPFR Interface. (line 20)
-* Precision: MPFR Basics. (line 65)
-* Reporting bugs: Reporting Bugs. (line 6)
-* Rounding mode related functions: Rounding Related Functions.
- (line 3)
-* Rounding Modes: MPFR Basics. (line 79)
-* Special functions: Special Functions. (line 3)
-* stdarg.h: MPFR Basics. (line 22)
-* stdio.h: MPFR Basics. (line 15)
-
-\1f
-File: mpfr.info, Node: Function Index, Prev: Concept Index, Up: Top
-
-Function and Type Index
-***********************
-
-\0\b[index\0\b]
-* Menu:
-
-* mp_prec_t: MPFR Basics. (line 65)
-* mp_rnd_t: MPFR Basics. (line 79)
-* mpfr_abs: Basic Arithmetic Functions.
- (line 177)
-* mpfr_acos: Special Functions. (line 48)
-* mpfr_acosh: Special Functions. (line 131)
-* mpfr_add: Basic Arithmetic Functions.
- (line 8)
-* mpfr_add_d: Basic Arithmetic Functions.
- (line 14)
-* mpfr_add_q: Basic Arithmetic Functions.
- (line 18)
-* mpfr_add_si: Basic Arithmetic Functions.
- (line 12)
-* mpfr_add_ui: Basic Arithmetic Functions.
- (line 10)
-* mpfr_add_z: Basic Arithmetic Functions.
- (line 16)
-* mpfr_agm: Special Functions. (line 221)
-* mpfr_asin: Special Functions. (line 49)
-* mpfr_asinh: Special Functions. (line 132)
-* mpfr_asprintf: Formatted Output Functions.
- (line 171)
-* mpfr_atan: Special Functions. (line 50)
-* mpfr_atan2: Special Functions. (line 60)
-* mpfr_atanh: Special Functions. (line 133)
-* mpfr_can_round: Rounding Related Functions.
- (line 29)
-* mpfr_cbrt: Basic Arithmetic Functions.
- (line 107)
-* mpfr_ceil: Integer Related Functions.
- (line 8)
-* mpfr_check_range: Exception Related Functions.
- (line 38)
-* mpfr_clear: Initialization Functions.
- (line 31)
-* mpfr_clear_erangeflag: Exception Related Functions.
- (line 111)
-* mpfr_clear_flags: Exception Related Functions.
- (line 121)
-* mpfr_clear_inexflag: Exception Related Functions.
- (line 110)
-* mpfr_clear_nanflag: Exception Related Functions.
- (line 109)
-* mpfr_clear_overflow: Exception Related Functions.
- (line 108)
-* mpfr_clear_underflow: Exception Related Functions.
- (line 107)
-* mpfr_clears: Initialization Functions.
- (line 35)
-* mpfr_cmp: Comparison Functions.
- (line 7)
-* mpfr_cmp_d: Comparison Functions.
- (line 10)
-* mpfr_cmp_f: Comparison Functions.
- (line 14)
-* mpfr_cmp_ld: Comparison Functions.
- (line 11)
-* mpfr_cmp_q: Comparison Functions.
- (line 13)
-* mpfr_cmp_si: Comparison Functions.
- (line 9)
-* mpfr_cmp_si_2exp: Comparison Functions.
- (line 31)
-* mpfr_cmp_ui: Comparison Functions.
- (line 8)
-* mpfr_cmp_ui_2exp: Comparison Functions.
- (line 29)
-* mpfr_cmp_z: Comparison Functions.
- (line 12)
-* mpfr_cmpabs: Comparison Functions.
- (line 35)
-* mpfr_const_catalan: Special Functions. (line 242)
-* mpfr_const_euler: Special Functions. (line 241)
-* mpfr_const_log2: Special Functions. (line 239)
-* mpfr_const_pi: Special Functions. (line 240)
-* mpfr_copysign: Miscellaneous Functions.
- (line 93)
-* mpfr_cos: Special Functions. (line 29)
-* mpfr_cosh: Special Functions. (line 111)
-* mpfr_cot: Special Functions. (line 37)
-* mpfr_coth: Special Functions. (line 127)
-* mpfr_csc: Special Functions. (line 36)
-* mpfr_csch: Special Functions. (line 126)
-* mpfr_custom_get_exp: Custom Interface. (line 78)
-* mpfr_custom_get_kind: Custom Interface. (line 67)
-* mpfr_custom_get_mantissa: Custom Interface. (line 72)
-* mpfr_custom_get_size: Custom Interface. (line 38)
-* mpfr_custom_init: Custom Interface. (line 42)
-* mpfr_custom_init_set: Custom Interface. (line 48)
-* mpfr_custom_move: Custom Interface. (line 85)
-* mpfr_d_div: Basic Arithmetic Functions.
- (line 82)
-* mpfr_d_sub: Basic Arithmetic Functions.
- (line 37)
-* MPFR_DECL_INIT: Initialization Functions.
- (line 75)
-* mpfr_dim: Basic Arithmetic Functions.
- (line 182)
-* mpfr_div: Basic Arithmetic Functions.
- (line 72)
-* mpfr_div_2exp: Compatibility with MPF.
- (line 49)
-* mpfr_div_2si: Basic Arithmetic Functions.
- (line 197)
-* mpfr_div_2ui: Basic Arithmetic Functions.
- (line 195)
-* mpfr_div_d: Basic Arithmetic Functions.
- (line 84)
-* mpfr_div_q: Basic Arithmetic Functions.
- (line 88)
-* mpfr_div_si: Basic Arithmetic Functions.
- (line 80)
-* mpfr_div_ui: Basic Arithmetic Functions.
- (line 76)
-* mpfr_div_z: Basic Arithmetic Functions.
- (line 86)
-* mpfr_eint: Special Functions. (line 150)
-* mpfr_eq: Compatibility with MPF.
- (line 28)
-* mpfr_equal_p: Comparison Functions.
- (line 71)
-* mpfr_erangeflag_p: Exception Related Functions.
- (line 129)
-* mpfr_erf: Special Functions. (line 186)
-* mpfr_erfc: Special Functions. (line 190)
-* mpfr_exp: Special Functions. (line 23)
-* mpfr_exp10: Special Functions. (line 25)
-* mpfr_exp2: Special Functions. (line 24)
-* mpfr_expm1: Special Functions. (line 146)
-* mpfr_fac_ui: Special Functions. (line 138)
-* mpfr_fits_intmax_p: Conversion Functions.
- (line 113)
-* mpfr_fits_sint_p: Conversion Functions.
- (line 110)
-* mpfr_fits_slong_p: Conversion Functions.
- (line 108)
-* mpfr_fits_sshort_p: Conversion Functions.
- (line 112)
-* mpfr_fits_uint_p: Conversion Functions.
- (line 109)
-* mpfr_fits_uintmax_p: Conversion Functions.
- (line 114)
-* mpfr_fits_ulong_p: Conversion Functions.
- (line 107)
-* mpfr_fits_ushort_p: Conversion Functions.
- (line 111)
-* mpfr_floor: Integer Related Functions.
- (line 9)
-* mpfr_fma: Special Functions. (line 213)
-* mpfr_fmod: Integer Related Functions.
- (line 63)
-* mpfr_fms: Special Functions. (line 217)
-* mpfr_fprintf: Formatted Output Functions.
- (line 117)
-* mpfr_frac: Integer Related Functions.
- (line 48)
-* mpfr_free_cache: Special Functions. (line 249)
-* mpfr_free_str: Conversion Functions.
- (line 100)
-* mpfr_gamma: Special Functions. (line 162)
-* mpfr_get_d: Conversion Functions.
- (line 7)
-* mpfr_get_d_2exp: Conversion Functions.
- (line 20)
-* mpfr_get_decimal64: Conversion Functions.
- (line 9)
-* mpfr_get_default_prec: Initialization Functions.
- (line 109)
-* mpfr_get_default_rounding_mode: Rounding Related Functions.
- (line 11)
-* mpfr_get_emax: Exception Related Functions.
- (line 8)
-* mpfr_get_emax_max: Exception Related Functions.
- (line 30)
-* mpfr_get_emax_min: Exception Related Functions.
- (line 29)
-* mpfr_get_emin: Exception Related Functions.
- (line 7)
-* mpfr_get_emin_max: Exception Related Functions.
- (line 28)
-* mpfr_get_emin_min: Exception Related Functions.
- (line 27)
-* mpfr_get_exp: Miscellaneous Functions.
- (line 71)
-* mpfr_get_f: Conversion Functions.
- (line 55)
-* mpfr_get_ld: Conversion Functions.
- (line 8)
-* mpfr_get_ld_2exp: Conversion Functions.
- (line 22)
-* mpfr_get_patches: Miscellaneous Functions.
- (line 130)
-* mpfr_get_prec: Initialization Functions.
- (line 143)
-* mpfr_get_si: Conversion Functions.
- (line 31)
-* mpfr_get_sj: Conversion Functions.
- (line 33)
-* mpfr_get_str: Conversion Functions.
- (line 61)
-* mpfr_get_ui: Conversion Functions.
- (line 32)
-* mpfr_get_uj: Conversion Functions.
- (line 34)
-* mpfr_get_version: Miscellaneous Functions.
- (line 99)
-* mpfr_get_z: Conversion Functions.
- (line 51)
-* mpfr_get_z_exp: Conversion Functions.
- (line 44)
-* mpfr_greater_p: Comparison Functions.
- (line 54)
-* mpfr_greaterequal_p: Comparison Functions.
- (line 57)
-* mpfr_hypot: Special Functions. (line 230)
-* mpfr_inexflag_p: Exception Related Functions.
- (line 128)
-* mpfr_inf_p: Comparison Functions.
- (line 42)
-* mpfr_init: Initialization Functions.
- (line 51)
-* mpfr_init2: Initialization Functions.
- (line 11)
-* mpfr_init_set: Combined Initialization and Assignment Functions.
- (line 7)
-* mpfr_init_set_d: Combined Initialization and Assignment Functions.
- (line 12)
-* mpfr_init_set_f: Combined Initialization and Assignment Functions.
- (line 17)
-* mpfr_init_set_ld: Combined Initialization and Assignment Functions.
- (line 14)
-* mpfr_init_set_q: Combined Initialization and Assignment Functions.
- (line 16)
-* mpfr_init_set_si: Combined Initialization and Assignment Functions.
- (line 11)
-* mpfr_init_set_str: Combined Initialization and Assignment Functions.
- (line 23)
-* mpfr_init_set_ui: Combined Initialization and Assignment Functions.
- (line 9)
-* mpfr_init_set_z: Combined Initialization and Assignment Functions.
- (line 15)
-* mpfr_inits: Initialization Functions.
- (line 63)
-* mpfr_inits2: Initialization Functions.
- (line 23)
-* mpfr_inp_str: Input and Output Functions.
- (line 33)
-* mpfr_integer_p: Integer Related Functions.
- (line 89)
-* mpfr_j0: Special Functions. (line 194)
-* mpfr_j1: Special Functions. (line 195)
-* mpfr_jn: Special Functions. (line 196)
-* mpfr_less_p: Comparison Functions.
- (line 60)
-* mpfr_lessequal_p: Comparison Functions.
- (line 63)
-* mpfr_lessgreater_p: Comparison Functions.
- (line 66)
-* mpfr_lgamma: Special Functions. (line 172)
-* mpfr_li2: Special Functions. (line 157)
-* mpfr_lngamma: Special Functions. (line 166)
-* mpfr_log: Special Functions. (line 16)
-* mpfr_log10: Special Functions. (line 18)
-* mpfr_log1p: Special Functions. (line 142)
-* mpfr_log2: Special Functions. (line 17)
-* mpfr_max: Miscellaneous Functions.
- (line 29)
-* mpfr_min: Miscellaneous Functions.
- (line 22)
-* mpfr_modf: Integer Related Functions.
- (line 55)
-* mpfr_mul: Basic Arithmetic Functions.
- (line 51)
-* mpfr_mul_2exp: Compatibility with MPF.
- (line 47)
-* mpfr_mul_2si: Basic Arithmetic Functions.
- (line 190)
-* mpfr_mul_2ui: Basic Arithmetic Functions.
- (line 188)
-* mpfr_mul_d: Basic Arithmetic Functions.
- (line 57)
-* mpfr_mul_q: Basic Arithmetic Functions.
- (line 61)
-* mpfr_mul_si: Basic Arithmetic Functions.
- (line 55)
-* mpfr_mul_ui: Basic Arithmetic Functions.
- (line 53)
-* mpfr_mul_z: Basic Arithmetic Functions.
- (line 59)
-* mpfr_nan_p: Comparison Functions.
- (line 41)
-* mpfr_nanflag_p: Exception Related Functions.
- (line 127)
-* mpfr_neg: Basic Arithmetic Functions.
- (line 173)
-* mpfr_nextabove: Miscellaneous Functions.
- (line 15)
-* mpfr_nextbelow: Miscellaneous Functions.
- (line 18)
-* mpfr_nexttoward: Miscellaneous Functions.
- (line 7)
-* mpfr_number_p: Comparison Functions.
- (line 43)
-* mpfr_out_str: Input and Output Functions.
- (line 17)
-* mpfr_overflow_p: Exception Related Functions.
- (line 126)
-* mpfr_pow: Basic Arithmetic Functions.
- (line 116)
-* mpfr_pow_si: Basic Arithmetic Functions.
- (line 120)
-* mpfr_pow_ui: Basic Arithmetic Functions.
- (line 118)
-* mpfr_pow_z: Basic Arithmetic Functions.
- (line 122)
-* mpfr_prec_round: Rounding Related Functions.
- (line 15)
-* mpfr_print_rnd_mode: Rounding Related Functions.
- (line 46)
-* mpfr_printf: Formatted Output Functions.
- (line 130)
-* mpfr_random: Miscellaneous Functions.
- (line 48)
-* mpfr_random2: Miscellaneous Functions.
- (line 56)
-* mpfr_rec_sqrt: Basic Arithmetic Functions.
- (line 102)
-* mpfr_reldiff: Compatibility with MPF.
- (line 39)
-* mpfr_remainder: Integer Related Functions.
- (line 65)
-* mpfr_remquo: Integer Related Functions.
- (line 67)
-* mpfr_rint: Integer Related Functions.
- (line 7)
-* mpfr_rint_ceil: Integer Related Functions.
- (line 34)
-* mpfr_rint_floor: Integer Related Functions.
- (line 35)
-* mpfr_rint_round: Integer Related Functions.
- (line 36)
-* mpfr_rint_trunc: Integer Related Functions.
- (line 37)
-* mpfr_root: Basic Arithmetic Functions.
- (line 109)
-* mpfr_round: Integer Related Functions.
- (line 10)
-* mpfr_round_prec: Rounding Related Functions.
- (line 25)
-* mpfr_sec: Special Functions. (line 35)
-* mpfr_sech: Special Functions. (line 125)
-* mpfr_set: Assignment Functions.
- (line 12)
-* mpfr_set_d: Assignment Functions.
- (line 18)
-* mpfr_set_decimal64: Assignment Functions.
- (line 21)
-* mpfr_set_default_prec: Initialization Functions.
- (line 101)
-* mpfr_set_default_rounding_mode: Rounding Related Functions.
- (line 7)
-* mpfr_set_emax: Exception Related Functions.
- (line 16)
-* mpfr_set_emin: Exception Related Functions.
- (line 15)
-* mpfr_set_erangeflag: Exception Related Functions.
- (line 118)
-* mpfr_set_exp: Miscellaneous Functions.
- (line 76)
-* mpfr_set_f: Assignment Functions.
- (line 24)
-* mpfr_set_inexflag: Exception Related Functions.
- (line 117)
-* mpfr_set_inf: Assignment Functions.
- (line 131)
-* mpfr_set_ld: Assignment Functions.
- (line 19)
-* mpfr_set_nan: Assignment Functions.
- (line 132)
-* mpfr_set_nanflag: Exception Related Functions.
- (line 116)
-* mpfr_set_overflow: Exception Related Functions.
- (line 115)
-* mpfr_set_prec: Initialization Functions.
- (line 131)
-* mpfr_set_prec_raw: Compatibility with MPF.
- (line 21)
-* mpfr_set_q: Assignment Functions.
- (line 23)
-* mpfr_set_si: Assignment Functions.
- (line 15)
-* mpfr_set_si_2exp: Assignment Functions.
- (line 51)
-* mpfr_set_sj: Assignment Functions.
- (line 17)
-* mpfr_set_sj_2exp: Assignment Functions.
- (line 55)
-* mpfr_set_str: Assignment Functions.
- (line 61)
-* mpfr_set_ui: Assignment Functions.
- (line 14)
-* mpfr_set_ui_2exp: Assignment Functions.
- (line 49)
-* mpfr_set_uj: Assignment Functions.
- (line 16)
-* mpfr_set_uj_2exp: Assignment Functions.
- (line 53)
-* mpfr_set_underflow: Exception Related Functions.
- (line 114)
-* mpfr_set_z: Assignment Functions.
- (line 22)
-* mpfr_setsign: Miscellaneous Functions.
- (line 87)
-* mpfr_sgn: Comparison Functions.
- (line 49)
-* mpfr_si_div: Basic Arithmetic Functions.
- (line 78)
-* mpfr_si_sub: Basic Arithmetic Functions.
- (line 33)
-* mpfr_signbit: Miscellaneous Functions.
- (line 82)
-* mpfr_sin: Special Functions. (line 30)
-* mpfr_sin_cos: Special Functions. (line 42)
-* mpfr_sinh: Special Functions. (line 112)
-* mpfr_sinh_cosh: Special Functions. (line 118)
-* mpfr_snprintf: Formatted Output Functions.
- (line 155)
-* mpfr_sprintf: Formatted Output Functions.
- (line 141)
-* mpfr_sqr: Basic Arithmetic Functions.
- (line 68)
-* mpfr_sqrt: Basic Arithmetic Functions.
- (line 95)
-* mpfr_sqrt_ui: Basic Arithmetic Functions.
- (line 97)
-* mpfr_strtofr: Assignment Functions.
- (line 72)
-* mpfr_sub: Basic Arithmetic Functions.
- (line 27)
-* mpfr_sub_d: Basic Arithmetic Functions.
- (line 39)
-* mpfr_sub_q: Basic Arithmetic Functions.
- (line 43)
-* mpfr_sub_si: Basic Arithmetic Functions.
- (line 35)
-* mpfr_sub_ui: Basic Arithmetic Functions.
- (line 31)
-* mpfr_sub_z: Basic Arithmetic Functions.
- (line 41)
-* mpfr_subnormalize: Exception Related Functions.
- (line 58)
-* mpfr_sum: Special Functions. (line 258)
-* mpfr_swap: Assignment Functions.
- (line 137)
-* mpfr_t: MPFR Basics. (line 52)
-* mpfr_tan: Special Functions. (line 31)
-* mpfr_tanh: Special Functions. (line 113)
-* mpfr_trunc: Integer Related Functions.
- (line 11)
-* mpfr_ui_div: Basic Arithmetic Functions.
- (line 74)
-* mpfr_ui_pow: Basic Arithmetic Functions.
- (line 126)
-* mpfr_ui_pow_ui: Basic Arithmetic Functions.
- (line 124)
-* mpfr_ui_sub: Basic Arithmetic Functions.
- (line 29)
-* mpfr_underflow_p: Exception Related Functions.
- (line 125)
-* mpfr_unordered_p: Comparison Functions.
- (line 75)
-* mpfr_urandomb: Miscellaneous Functions.
- (line 35)
-* mpfr_vasprintf: Formatted Output Functions.
- (line 173)
-* MPFR_VERSION: Miscellaneous Functions.
- (line 102)
-* MPFR_VERSION_MAJOR: Miscellaneous Functions.
- (line 103)
-* MPFR_VERSION_MINOR: Miscellaneous Functions.
- (line 104)
-* MPFR_VERSION_NUM: Miscellaneous Functions.
- (line 122)
-* MPFR_VERSION_PATCHLEVEL: Miscellaneous Functions.
- (line 105)
-* MPFR_VERSION_STRING: Miscellaneous Functions.
- (line 106)
-* mpfr_vfprintf: Formatted Output Functions.
- (line 119)
-* mpfr_vprintf: Formatted Output Functions.
- (line 131)
-* mpfr_vsnprintf: Formatted Output Functions.
- (line 157)
-* mpfr_vsprintf: Formatted Output Functions.
- (line 143)
-* mpfr_y0: Special Functions. (line 203)
-* mpfr_y1: Special Functions. (line 204)
-* mpfr_yn: Special Functions. (line 205)
-* mpfr_zero_p: Comparison Functions.
- (line 44)
-* mpfr_zeta: Special Functions. (line 180)
-* mpfr_zeta_ui: Special Functions. (line 182)
-
-
-\1f
-Tag Table:
-Node: Top\7f874
-Node: Copying\7f2113
-Node: Introduction to MPFR\7f3843
-Node: Installing MPFR\7f5755
-Node: Reporting Bugs\7f8997
-Node: MPFR Basics\7f10613
-Node: MPFR Interface\7f25127
-Node: Initialization Functions\7f27351
-Node: Assignment Functions\7f33919
-Node: Combined Initialization and Assignment Functions\7f41669
-Node: Conversion Functions\7f42951
-Node: Basic Arithmetic Functions\7f49151
-Node: Comparison Functions\7f58008
-Node: Special Functions\7f61430
-Node: Input and Output Functions\7f73827
-Node: Formatted Output Functions\7f75757
-Node: Integer Related Functions\7f84168
-Node: Rounding Related Functions\7f89004
-Node: Miscellaneous Functions\7f91474
-Node: Exception Related Functions\7f98260
-Node: Compatibility with MPF\7f104378
-Node: Custom Interface\7f106870
-Node: Internals\7f111053
-Node: Contributors\7f112376
-Node: References\7f114541
-Node: GNU Free Documentation License\7f115655
-Node: Concept Index\7f138098
-Node: Function Index\7f142890
-\1f
-End Tag Table
-
-\1f
-Local Variables:
-coding: iso-8859-1
-End:
projects / msp430-gcc.git / commitdiff