| This is doc/gcc.info, produced by makeinfo version 4.13 from |
| /tmp/android-8532/src/build/../gcc/gcc-4.6/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, 2009, 2010 |
| Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being "Funding Free Software", the Front-Cover Texts |
| being (a) (see below), and with the Back-Cover Texts being (b) (see |
| below). A copy of the license is included in the section entitled "GNU |
| Free Documentation License". |
| |
| (a) The FSF's Front-Cover Text is: |
| |
| A GNU Manual |
| |
| (b) The FSF's Back-Cover Text is: |
| |
| You have freedom to copy and modify this GNU Manual, like GNU |
| software. Copies published by the Free Software Foundation raise |
| funds for GNU development. |
| |
| INFO-DIR-SECTION Software development |
| START-INFO-DIR-ENTRY |
| * gcc: (gcc). The GNU Compiler Collection. |
| * g++: (gcc). The GNU C++ compiler. |
| 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, 2009, 2010 |
| Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being "Funding Free Software", the Front-Cover Texts |
| being (a) (see below), and with the Back-Cover Texts being (b) (see |
| below). A copy of the license is included in the section entitled "GNU |
| Free Documentation License". |
| |
| (a) The FSF's Front-Cover Text is: |
| |
| A GNU Manual |
| |
| (b) The FSF's Back-Cover Text is: |
| |
| You have freedom to copy and modify this GNU Manual, like GNU |
| software. Copies published by the Free Software Foundation raise |
| funds for GNU development. |
| |
| |
| |
| File: gcc.info, Node: Top, Next: G++ and GCC, Up: (DIR) |
| |
| Introduction |
| ************ |
| |
| This manual documents how to use the GNU compilers, as well as their |
| features and incompatibilities, and how to report bugs. It corresponds |
| to the compilers (GCC) version 4.6.x-google. 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++ Implementation:: How GCC implements the ISO C++ specification. |
| * 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. |
| |
| |
| 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, Ada, and Go. |
| |
| The abbreviation "GCC" has multiple meanings in common use. The |
| current official meaning is "GNU Compiler Collection", which refers |
| generically to the complete suite of tools. The name historically stood |
| for "GNU C Compiler", and this usage is still common when the emphasis |
| is on compiling C programs. Finally, the name is also used when |
| speaking of the "language-independent" component of GCC: code shared |
| among the compilers for all supported languages. |
| |
| The language-independent component of GCC includes the majority of the |
| optimizers, as well as the "back ends" that generate machine code for |
| various processors. |
| |
| The part of a compiler that is specific to a particular language is |
| called the "front end". In addition to the front ends that are |
| integrated components of GCC, there are several other front ends that |
| are maintained separately. These support languages such as Pascal, |
| Mercury, and COBOL. To use these, they must be built together with GCC |
| proper. |
| |
| Most of the compilers for languages other than C have their own names. |
| The C++ compiler is G++, the Ada compiler is GNAT, and so on. When we |
| talk about compiling one of those languages, we might refer to that |
| compiler by its own name, or as GCC. Either is correct. |
| |
| Historically, compilers for many languages, including C++ and Fortran, |
| have been implemented as "preprocessors" which emit another high level |
| language such as C. None of the compilers included in GCC are |
| implemented this way; they all generate machine code directly. This |
| sort of preprocessor should not be confused with the "C preprocessor", |
| which is an integral feature of the C, C++, Objective-C and |
| Objective-C++ languages. |
| |
| |
| File: gcc.info, Node: Standards, Next: Invoking GCC, Prev: G++ and GCC, Up: Top |
| |
| 2 Language Standards Supported by GCC |
| ************************************* |
| |
| For each language compiled by GCC for which there is a standard, GCC |
| attempts to follow one or more versions of that standard, possibly with |
| some exceptions, and possibly with some extensions. |
| |
| 2.1 C language |
| ============== |
| |
| GCC supports three versions of the C standard, although support for the |
| most recent version is not yet complete. |
| |
| The original ANSI C standard (X3.159-1989) was ratified in 1989 and |
| published in 1990. This standard was ratified as an ISO standard |
| (ISO/IEC 9899:1990) later in 1990. There were no technical differences |
| between these publications, although the sections of the ANSI standard |
| were renumbered and became clauses in the ISO standard. This standard, |
| in both its forms, is commonly known as "C89", or occasionally as |
| "C90", from the dates of ratification. The ANSI standard, but not the |
| ISO standard, also came with a Rationale document. To select this |
| standard in GCC, use one of the options `-ansi', `-std=c90' or |
| `-std=iso9899:1990'; to obtain all the diagnostics required by the |
| standard, you should also specify `-pedantic' (or `-pedantic-errors' if |
| you want them to be errors rather than warnings). *Note Options |
| Controlling C Dialect: C Dialect Options. |
| |
| Errors in the 1990 ISO C standard were corrected in two Technical |
| Corrigenda published in 1994 and 1996. GCC does not support the |
| uncorrected version. |
| |
| An amendment to the 1990 standard was published in 1995. This |
| amendment added digraphs and `__STDC_VERSION__' to the language, but |
| otherwise concerned the library. This amendment is commonly known as |
| "AMD1"; the amended standard is sometimes known as "C94" or "C95". To |
| select this standard in GCC, use the option `-std=iso9899:199409' |
| (with, as for other standard versions, `-pedantic' to receive all |
| required diagnostics). |
| |
| A new edition of the ISO C standard was published in 1999 as ISO/IEC |
| 9899:1999, and is commonly known as "C99". GCC has incomplete support |
| for this standard version; see |
| `http://gcc.gnu.org/gcc-4.6/c99status.html' for details. To select this |
| standard, use `-std=c99' or `-std=iso9899:1999'. (While in |
| development, drafts of this standard version were referred to as "C9X".) |
| |
| Errors in the 1999 ISO C standard were corrected in three Technical |
| Corrigenda published in 2001, 2004 and 2007. GCC does not support the |
| uncorrected version. |
| |
| A fourth version of the C standard, known as "C1X", is under |
| development; GCC has limited preliminary support for parts of this |
| standard, enabled with `-std=c1x'. |
| |
| By default, GCC provides some extensions to the C language that on |
| rare occasions conflict with the C standard. *Note Extensions to the C |
| Language Family: C Extensions. Use of the `-std' options listed above |
| will disable these extensions where they conflict with the C standard |
| version selected. You may also select an extended version of the C |
| language explicitly with `-std=gnu90' (for C90 with GNU extensions), |
| `-std=gnu99' (for C99 with GNU extensions) or `-std=gnu1x' (for C1X |
| with GNU extensions). The default, if no C language dialect options |
| are given, is `-std=gnu90'; 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 C90 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/projects/cxx0x.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 |
| =========================================== |
| |
| GCC supports "traditional" Objective-C (also known as "Objective-C |
| 1.0") and contains support for the Objective-C exception and |
| synchronization syntax. It has also support for a number of |
| "Objective-C 2.0" language extensions, including properties, fast |
| enumeration (only for Objective-C), method attributes and the @optional |
| and @required keywords in protocols. GCC supports Objective-C++ and |
| features available in Objective-C are also available in Objective-C++. |
| |
| GCC by default uses the GNU Objective-C runtime library, which is part |
| of GCC and is not the same as the Apple/NeXT Objective-C runtime |
| library used on Apple systems. There are a number of differences |
| documented in this manual. The options `-fgnu-runtime' and |
| `-fnext-runtime' allow you to switch between producing output that |
| works with the GNU Objective-C runtime library and output that works |
| with the Apple/NeXT Objective-C runtime library. |
| |
| There is no formal written standard for Objective-C or Objective-C++. |
| The authoritative manual on traditional Objective-C (1.0) is |
| "Object-Oriented Programming and the Objective-C Language", available |
| at a number of web sites: |
| * `http://www.gnustep.org/resources/documentation/ObjectivCBook.pdf' |
| is the original NeXTstep document; |
| |
| * `http://objc.toodarkpark.net' is the same document in another |
| format; |
| |
| * |
| `http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/' |
| has an updated version but make sure you search for "Object |
| Oriented Programming and the Objective-C Programming Language 1.0", |
| not documentation on the newer "Objective-C 2.0" language |
| |
| The Objective-C exception and synchronization syntax (that is, the |
| keywords @try, @throw, @catch, @finally and @synchronized) is supported |
| by GCC and is enabled with the option `-fobjc-exceptions'. The syntax |
| is briefly documented in this manual and in the Objective-C 2.0 manuals |
| from Apple. |
| |
| The Objective-C 2.0 language extensions and features are automatically |
| enabled; they include properties (via the @property, @synthesize and |
| @dynamic keywords), fast enumeration (not available in Objective-C++), |
| attributes for methods (such as deprecated, noreturn, sentinel, |
| format), the unused attribute for method arguments, the @package |
| keyword for instance variables and the @optional and @required keywords |
| in protocols. You can disable all these Objective-C 2.0 language |
| extensions with the option `-fobjc-std=objc1', which causes the |
| compiler to recognize the same Objective-C language syntax recognized |
| by GCC 4.0, and to produce an error if one of the new features is used. |
| |
| GCC has currently no support for non-fragile instance variables. |
| |
| The authoritative manual on Objective-C 2.0 is available from Apple: |
| * |
| `http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/' |
| |
| For more information concerning the history of Objective-C that is |
| available online, see `http://gcc.gnu.org/readings.html' |
| |
| 2.4 Go language |
| =============== |
| |
| The Go language continues to evolve as of this writing; see the current |
| language specifications (http://golang.org/doc/go_spec.html). At |
| present there are no specific versions of Go, and there is no way to |
| describe the language supported by GCC in terms of a specific version. |
| In general GCC tracks the evolving specification closely, and any given |
| release will support the language as of the date that the release was |
| frozen. |
| |
| 2.5 References for other languages |
| ================================== |
| |
| *Note GNAT Reference Manual: (gnat_rm)Top, for information on standard |
| conformance and compatibility of the Ada compiler. |
| |
| *Note Standards: (gfortran)Standards, for details of standards |
| supported by GNU Fortran. |
| |
| *Note Compatibility with the Java Platform: (gcj)Compatibility, for |
| details of compatibility between `gcj' and the Java Platform. |
| |
| |
| File: gcc.info, Node: Invoking GCC, Next: C Implementation, Prev: Standards, Up: Top |
| |
| 3 GCC Command Options |
| ********************* |
| |
| When you invoke GCC, it normally does preprocessing, compilation, |
| assembly and linking. The "overall options" allow you to stop this |
| process at an intermediate stage. For example, the `-c' option says |
| not to run the linker. Then the output consists of object files output |
| by the assembler. |
| |
| Other options are passed on to one stage of processing. Some options |
| control the preprocessor and others the compiler itself. Yet other |
| options control the assembler and linker; most of these are not |
| documented here, since you rarely need to use any of them. |
| |
| Most of the command line options that you can use with GCC are useful |
| for C programs; when an option is only useful with another language |
| (usually C++), the explanation says so explicitly. If the description |
| for a particular option does not mention a source language, you can use |
| that option with all supported languages. |
| |
| *Note Compiling C++ Programs: Invoking G++, for a summary of special |
| options for compiling C++ programs. |
| |
| The `gcc' program accepts options and file names as operands. Many |
| options have multi-letter names; therefore multiple single-letter |
| options may _not_ be grouped: `-dv' is very different from `-d -v'. |
| |
| You can mix options and other arguments. For the most part, the order |
| you use doesn't matter. Order does matter when you use several options |
| of the same kind; for example, if you specify `-L' more than once, the |
| directories are searched in the order specified. Also, the placement |
| of the `-l' option is significant. |
| |
| Many options have long names starting with `-f' or with `-W'--for |
| example, `-fmove-loop-invariants', `-Wformat' and so on. Most of these |
| have both positive and negative forms; the negative form of `-ffoo' |
| 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. |
| |
| |
| File: gcc.info, Node: Option Summary, Next: Overall Options, Up: Invoking GCC |
| |
| 3.1 Option Summary |
| ================== |
| |
| Here is a summary of all the options, grouped by type. Explanations are |
| in the following sections. |
| |
| _Overall Options_ |
| *Note Options Controlling the Kind of Output: Overall Options. |
| -c -S -E -o FILE -no-canonical-prefixes |
| -pipe -pass-exit-codes |
| -x LANGUAGE -v -### --help[=CLASS[,...]] --target-help |
| --version -wrapper @FILE -fplugin=FILE -fplugin-arg-NAME=ARG |
| -fdump-ada-spec[-slim] |
| -fdump-go-spec=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 -fplan9-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 -fconstexpr-depth=N -ffriend-injection |
| -fno-elide-constructors |
| -fno-enforce-eh-specs |
| -ffor-scope -fno-for-scope -fno-gnu-keywords |
| -fno-implicit-templates |
| -fno-implicit-inline-templates |
| -fno-implement-inlines -fms-extensions |
| -fno-nonansi-builtins -fnothrow-opt -fno-operator-names |
| -fno-optional-diags -fpermissive |
| -fno-pretty-templates |
| -frepo -fno-rtti -fstats -ftemplate-depth=N |
| -fno-threadsafe-statics -fuse-cxa-atexit -fno-weak -nostdinc++ |
| -fno-default-inline -fvisibility-inlines-hidden |
| -fvisibility-ms-compat |
| -Wabi -Wconversion-null -Wctor-dtor-privacy |
| -Wnoexcept -Wnon-virtual-dtor -Wreorder |
| -Weffc++ -Wstrict-null-sentinel |
| -Wno-non-template-friend -Wold-style-cast |
| -Woverloaded-virtual -Wno-pmf-conversions |
| -Wsign-promo |
| |
| _Objective-C and Objective-C++ Language Options_ |
| *Note Options Controlling Objective-C and Objective-C++ Dialects: |
| Objective-C and Objective-C++ Dialect Options. |
| -fconstant-string-class=CLASS-NAME |
| -fgnu-runtime -fnext-runtime |
| -fno-nil-receivers |
| -fobjc-abi-version=N |
| -fobjc-call-cxx-cdtors |
| -fobjc-direct-dispatch |
| -fobjc-exceptions |
| -fobjc-gc |
| -fobjc-nilcheck |
| -fobjc-std=objc1 |
| -freplace-objc-classes |
| -fzero-link |
| -gen-decls |
| -Wassign-intercept |
| -Wno-protocol -Wselector |
| -Wstrict-selector-match |
| -Wundeclared-selector |
| |
| _Language Independent Options_ |
| *Note Options to Control Diagnostic Messages Formatting: Language |
| Independent Options. |
| -fmessage-length=N |
| -fdiagnostics-show-location=[once|every-line] |
| -fno-diagnostics-show-option |
| |
| _Warning Options_ |
| *Note Options to Request or Suppress Warnings: Warning Options. |
| -fsyntax-only -fmax-errors=N -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-cpp -Wno-deprecated |
| -Wno-deprecated-declarations -Wdisabled-optimization |
| -Wno-div-by-zero -Wdouble-promotion -Wempty-body -Wenum-compare |
| -Wno-endif-labels -Werror -Werror=* |
| -Wfatal-errors -Wfloat-equal -Wformat -Wformat=2 |
| -Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral |
| -Wformat-security -Wformat-y2k |
| -Wframe-larger-than=LEN -Wjump-misses-init -Wignored-qualifiers |
| -Wimplicit -Wimplicit-function-declaration -Wimplicit-int |
| -Winit-self -Winline -Wmaybe-uninitialized |
| -Wno-int-to-pointer-cast -Wno-invalid-offsetof |
| -Winvalid-pch -Wlarger-than=LEN -Wunsafe-loop-optimizations |
| -Wlogical-op -Wlong-long |
| -Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers |
| -Wmissing-format-attribute -Wmissing-include-dirs |
| -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 |
| -Wreal-conversion -Wredundant-decls -Wreturn-type -Wripa-opt-mismatch |
| -Wself-assign -Wself-assign-non-pod -Wsequence-point -Wshadow |
| -Wshadow-compatible-local -Wshadow-local |
| -Wsign-compare -Wsign-conversion -Wstack-protector |
| -Wstrict-aliasing -Wstrict-aliasing=n |
| -Wstrict-overflow -Wstrict-overflow=N |
| -Wsuggest-attribute=[pure|const|noreturn] |
| -Wswitch -Wswitch-default -Wswitch-enum -Wsync-nand |
| -Wsystem-headers -Wthread-safety -Wthread-unguarded-var |
| -Wthread-unguarded-func -Wthread-mismatched-lock-order |
| -Wthread-mismatched-lock-acq-rel -Wthread-reentrant-lock |
| -Wthread-unsupported-lock-name -Wthread-attr-bind-param |
| -Wtrampolines -Wtrigraphs -Wtype-limits -Wundef |
| -Wuninitialized -Wunknown-pragmas -Wno-pragmas |
| -Wunsuffixed-float-constants -Wunused -Wunused-function |
| -Wunused-label -Wunused-parameter -Wno-unused-result -Wunused-value |
| -Wunused-variable -Wunused-but-set-parameter -Wunused-but-set-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 |
| -fdisable-ipa-PASS_NAME |
| -fdisable-rtl-PASS_NAME |
| -fdisable-rtl-PASS-NAME=RANGE-LIST |
| -fdisable-tree-PASS_NAME |
| -fdisable-tree-PASS-NAME=RANGE-LIST |
| -fdump-noaddr -fdump-unnumbered -fdump-unnumbered-links |
| -fdump-translation-unit[-N] |
| -fdump-class-hierarchy[-N] |
| -fdump-ipa-all -fdump-ipa-cgraph -fdump-ipa-inline |
| -fdump-passes |
| -fdump-statistics |
| -fdump-tree-all |
| -fdump-tree-original[-N] |
| -fdump-tree-optimized[-N] |
| -fdump-tree-cfg -fdump-tree-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-phiprop[-N] |
| -fdump-tree-phiopt[-N] |
| -fdump-tree-forwprop[-N] |
| -fdump-tree-copyrename[-N] |
| -fdump-tree-nrv -fdump-tree-vect |
| -fdump-tree-sink |
| -fdump-tree-sra[-N] |
| -fdump-tree-forwprop[-N] |
| -fdump-tree-fre[-N] |
| -fdump-tree-vrp[-N] |
| -ftree-vectorizer-verbose=N |
| -fdump-tree-storeccp[-N] |
| -fdump-final-insns=FILE |
| -fcompare-debug[=OPTS] -fcompare-debug-second |
| -feliminate-dwarf2-dups -feliminate-unused-debug-types |
| -feliminate-unused-debug-symbols -femit-class-debug-always |
| -fenable-icf-debug |
| -fenable-KIND-PASS |
| -fenable-KIND-PASS=RANGE-LIST |
| -fdebug-types-section |
| -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 |
| -fstack-usage -ftest-coverage -ftime-report -fvar-tracking |
| -fvar-tracking-assignments -fvar-tracking-assignments-toggle |
| -g -gLEVEL -gtoggle -gcoff -gdwarf-VERSION |
| -ggdb -gmlt -gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf |
| -gvms -gxcoff -gxcoff+ |
| -fno-merge-debug-strings -fno-dwarf2-cfi-asm |
| -fdebug-prefix-map=OLD=NEW |
| -femit-struct-debug-baseonly -femit-struct-debug-reduced |
| -femit-struct-debug-detailed[=SPEC-LIST] |
| -p -pg -print-file-name=LIBRARY -print-libgcc-file-name |
| -print-multi-directory -print-multi-lib -print-multi-os-directory |
| -print-prog-name=PROGRAM -print-search-dirs -Q |
| -print-sysroot -print-sysroot-headers-suffix |
| -save-temps -save-temps=cwd -save-temps=obj -time[=FILE] |
| |
| _Optimization Options_ |
| *Note Options that Control Optimization: Optimize Options. |
| -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 |
| -fcallgraph-profiles-sections -fcheck-data-deps -fclone-hot-version-paths |
| -fcombine-stack-adjustments -fconserve-stack |
| -fcompare-elim -fcprop-registers -fcrossjumping |
| -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules |
| -fcx-limited-range |
| -fdata-sections -fdce -fdce -fdelayed-branch |
| -fdelete-null-pointer-checks -fdse -fdevirtualize -fdse |
| -fearly-inlining -fipa-sra -fexpensive-optimizations -ffast-math |
| -ffinite-math-only -ffloat-store -fexcess-precision=STYLE |
| -fforward-propagate -ffp-contract=STYLE -ffunction-sections |
| -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity |
| -fgcse-sm -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-profile -fipa-pure-const -fipa-reference |
| -fipa-struct-reorg -fira-algorithm=ALGORITHM |
| -fira-region=REGION |
| -fira-loop-pressure -fno-ira-share-save-slots |
| -fno-ira-share-spill-slots -fira-verbose=N |
| -fivopts -fkeep-inline-functions -fkeep-static-consts |
| -floop-block -floop-flatten -floop-interchange -floop-strip-mine |
| -floop-parallelize-all -flto -flto-compression-level |
| -flto-partition=ALG -flto-report -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 |
| -fpartial-inlining -fpeel-loops -fpredictive-commoning |
| -fprefetch-loop-arrays |
| -fprofile-correction -fprofile-dir=PATH -fprofile-generate |
| -fprofile-generate=PATH -fprofile-generate-sampling |
| -fprofile-use -fprofile-use=PATH -fprofile-values |
| -fpmu-profile-generate=PMUOPTION |
| -fpmu-profile-use=PMUOPTION |
| -freciprocal-math -fregmove -frename-registers -freorder-blocks |
| -frecord-gcc-switches-in-elf |
| -freorder-blocks-and-partition -freorder-functions |
| -frerun-cse-after-loop -freschedule-modulo-scheduled-loops |
| -fripa -fripa-disallow-asm-modules -fripa-disallow-opt-mismatch |
| -fripa-no-promote-always-inline-func -fripa-verbose |
| -fripa-peel-size-limit -fripa-unroll-size-limit -frounding-math |
| -fsched2-use-superblocks -fsched-pressure |
| -fsched-spec-load -fsched-spec-load-dangerous |
| -fsched-stalled-insns-dep[=N] -fsched-stalled-insns[=N] |
| -fsched-group-heuristic -fsched-critical-path-heuristic |
| -fsched-spec-insn-heuristic -fsched-rank-heuristic |
| -fsched-last-insn-heuristic -fsched-dep-count-heuristic |
| -fschedule-insns -fschedule-insns2 -fsection-anchors |
| -fselective-scheduling -fselective-scheduling2 |
| -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops |
| -fsignaling-nans -fsingle-precision-constant -fsplit-ivs-in-unroller |
| -fsplit-wide-types -fstack-protector -fstack-protector-all |
| -fstack-protector-strong -fstrict-aliasing -fstrict-overflow |
| -fthread-jumps -ftracer -ftree-bit-ccp |
| -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop |
| -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse |
| -ftree-forwprop -ftree-fre -ftree-loop-if-convert |
| -ftree-loop-if-convert-stores -ftree-loop-im |
| -ftree-phiprop -ftree-loop-distribution -ftree-loop-distribute-patterns |
| -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize |
| -ftree-parallelize-loops=N -ftree-pre -ftree-pta -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 -fwpa -fuse-ld -fuse-linker-plugin |
| --param NAME=VALUE |
| -O -O0 -O1 -O2 -O3 -Os -Ofast |
| |
| _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 -static-libstdc++ -shared |
| -shared-libgcc -symbolic |
| -T SCRIPT -Wl,OPTION -Xlinker OPTION |
| -u SYMBOL |
| |
| _Directory Options_ |
| *Note Options for Directory Search: Directory Options. |
| -BPREFIX -IDIR -iplugindir=DIR |
| |
| -iquoteDIR -LDIR -specs=FILE -I- -sysroot=DIR |
| |
| _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 |
| -mfp16-format=NAME |
| -mthumb-interwork -mno-thumb-interwork |
| -mcpu=NAME -march=NAME -mfpu=NAME |
| -mstructure-size-boundary=N |
| -mabort-on-noreturn |
| -mlong-calls -mno-long-calls |
| -msingle-pic-base -mno-single-pic-base |
| -mpic-register=REG |
| -mnop-fun-dllimport |
| -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 -mno-interrupts |
| -mcall-prologues -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 -mdebug-main=PREFIX -mmalloc64 |
| |
| _FR30 Options_ |
| -msmall-model -mno-lsim |
| |
| _FRV Options_ |
| -mgpr-32 -mgpr-64 -mfpr-32 -mfpr-64 |
| -mhard-float -msoft-float |
| -malloc-cc -mfixed-cc -mdword -mno-dword |
| -mdouble -mno-double |
| -mmedia -mno-media -mmuladd -mno-muladd |
| -mfdpic -minline-plt -mgprel-ro -multilib-library-pic |
| -mlinked-fp -mlong-calls -malign-labels |
| -mlibrary-pic -macc-4 -macc-8 |
| -mpack -mno-pack -mno-eflags -mcond-move -mno-cond-move |
| -moptimize-membar -mno-optimize-membar |
| -mscc -mno-scc -mcond-exec -mno-cond-exec |
| -mvliw-branch -mno-vliw-branch |
| -mmulti-cond-exec -mno-multi-cond-exec -mnested-cond-exec |
| -mno-nested-cond-exec -mtomcat-stats |
| -mTLS -mtls |
| -mcpu=CPU |
| |
| _GNU/Linux Options_ |
| -mglibc -muclibc -mbionic -mandroid |
| -tno-android-cc -tno-android-ld |
| |
| _H8/300 Options_ |
| -mrelax -mh -ms -mn -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 -mmovbe -mcrc32 -mrecip -mvzeroupper |
| -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx |
| -maes -mpclmul -mfsgsbase -mrdrnd -mf16c -mfused-madd |
| -msse4a -m3dnow -mpopcnt -mabm -mbmi -mtbm -mfma4 -mxop -mlwp |
| -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 -mvect8-ret-in-mem |
| -mpc32 -mpc64 -mpc80 -mstackrealign |
| -momit-leaf-frame-pointer -mno-red-zone -mno-tls-direct-seg-refs |
| -mcmodel=CODE-MODEL -mabi=NAME |
| -m32 -m64 -mlarge-data-threshold=NUM |
| -msse2avx -mfentry -m8bit-idiv |
| -mavx256-split-unaligned-load -mavx256-split-unaligned-store |
| |
| _i386 and x86-64 Windows Options_ |
| -mconsole -mcygwin -mno-cygwin -mdll |
| -mnop-fun-dllimport -mthread |
| -municode -mwin32 -mwindows -fno-set-stack-executable |
| |
| _IA-64 Options_ |
| -mbig-endian -mlittle-endian -mgnu-as -mgnu-ld -mno-pic |
| -mvolatile-asm-stop -mregister-names -msdata -mno-sdata |
| -mconstant-gp -mauto-pic -mfused-madd |
| -minline-float-divide-min-latency |
| -minline-float-divide-max-throughput |
| -mno-inline-float-divide |
| -minline-int-divide-min-latency |
| -minline-int-divide-max-throughput |
| -mno-inline-int-divide |
| -minline-sqrt-min-latency -minline-sqrt-max-throughput |
| -mno-inline-sqrt |
| -mdwarf2-asm -mearly-stop-bits |
| -mfixed-range=REGISTER-RANGE -mtls-size=TLS-SIZE |
| -mtune=CPU-TYPE -milp32 -mlp64 |
| -msched-br-data-spec -msched-ar-data-spec -msched-control-spec |
| -msched-br-in-data-spec -msched-ar-in-data-spec -msched-in-control-spec |
| -msched-spec-ldc -msched-spec-control-ldc |
| -msched-prefer-non-data-spec-insns -msched-prefer-non-control-spec-insns |
| -msched-stop-bits-after-every-cycle -msched-count-spec-in-critical-path |
| -msel-sched-dont-check-control-spec -msched-fp-mem-deps-zero-cost |
| -msched-max-memory-insns-hard-limit -msched-max-memory-insns=MAX-INSNS |
| |
| _IA-64/VMS Options_ |
| -mvms-return-codes -mdebug-main=PREFIX -mmalloc64 |
| |
| _LM32 Options_ |
| -mbarrel-shift-enabled -mdivide-enabled -mmultiply-enabled |
| -msign-extend-enabled -muser-enabled |
| |
| _M32R/D Options_ |
| -m32r2 -m32rx -m32r |
| -mdebug |
| -malign-loops -mno-align-loops |
| -missue-rate=NUMBER |
| -mbranch-cost=NUMBER |
| -mmodel=CODE-SIZE-MODEL-TYPE |
| -msdata=SDATA-TYPE |
| -mno-flush-func -mflush-func=NAME |
| -mno-flush-trap -mflush-trap=NUMBER |
| -G NUM |
| |
| _M32C Options_ |
| -mcpu=CPU -msim -memregs=NUMBER |
| |
| _M680x0 Options_ |
| -march=ARCH -mcpu=CPU -mtune=TUNE |
| -m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040 |
| -m68060 -mcpu32 -m5200 -m5206e -m528x -m5307 -m5407 |
| -mcfv4e -mbitfield -mno-bitfield -mc68000 -mc68020 |
| -mnobitfield -mrtd -mno-rtd -mdiv -mno-div -mshort |
| -mno-short -mhard-float -m68881 -msoft-float -mpcrel |
| -malign-int -mstrict-align -msep-data -mno-sep-data |
| -mshared-library-id=n -mid-shared-library -mno-id-shared-library |
| -mxgot -mno-xgot |
| |
| _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 |
| |
| _MeP Options_ |
| -mabsdiff -mall-opts -maverage -mbased=N -mbitops |
| -mc=N -mclip -mconfig=NAME -mcop -mcop32 -mcop64 -mivc2 |
| -mdc -mdiv -meb -mel -mio-volatile -ml -mleadz -mm -mminmax |
| -mmult -mno-opts -mrepeat -ms -msatur -msdram -msim -msimnovec -mtf |
| -mtiny=N |
| |
| _MicroBlaze Options_ |
| -msoft-float -mhard-float -msmall-divides -mcpu=CPU |
| -mmemcpy -mxl-soft-mul -mxl-soft-div -mxl-barrel-shift |
| -mxl-pattern-compare -mxl-stack-check -mxl-gp-opt -mno-clearbss |
| -mxl-multiply-high -mxl-float-convert -mxl-float-sqrt |
| -mxl-mode-APP-MODEL |
| |
| _MIPS Options_ |
| -EL -EB -march=ARCH -mtune=ARCH |
| -mips1 -mips2 -mips3 -mips4 -mips32 -mips32r2 |
| -mips64 -mips64r2 |
| -mips16 -mno-mips16 -mflip-mips16 |
| -minterlink-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 -msynci -mno-synci |
| -mrelax-pic-calls -mno-relax-pic-calls -mmcount-ra-address |
| |
| _MMIX Options_ |
| -mlibfuncs -mno-libfuncs -mepsilon -mno-epsilon -mabi=gnu |
| -mabi=mmixware -mzero-extend -mknuthdiv -mtoplevel-symbols |
| -melf -mbranch-predict -mno-branch-predict -mbase-addresses |
| -mno-base-addresses -msingle-exit -mno-single-exit |
| |
| _MN10300 Options_ |
| -mmult-bug -mno-mult-bug |
| -mno-am33 -mam33 -mam33-2 -mam34 |
| -mtune=CPU-TYPE |
| -mreturn-pointer-on-d0 |
| -mno-crt0 -mrelax -mliw |
| |
| _PDP-11 Options_ |
| -mfpu -msoft-float -mac0 -mno-ac0 -m40 -m45 -m10 |
| -mbcopy -mbcopy-builtin -mint32 -mno-int16 |
| -mint16 -mno-int32 -mfloat32 -mno-float64 |
| -mfloat64 -mno-float32 -mabshi -mno-abshi |
| -mbranch-expensive -mbranch-cheap |
| -munix-asm -mdec-asm |
| |
| _picoChip Options_ |
| -mae=AE_TYPE -mvliw-lookahead=N |
| -msymbol-as-address -mno-inefficient-warnings |
| |
| _PowerPC Options_ See RS/6000 and PowerPC Options. |
| |
| _RS/6000 and PowerPC Options_ |
| -mcpu=CPU-TYPE |
| -mtune=CPU-TYPE |
| -mcmodel=CODE-MODEL |
| -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 -mpopcntd -mno-popcntd |
| -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 -msingle-pic-base |
| -mprioritize-restricted-insns=PRIORITY |
| -msched-costly-dep=DEPENDENCE_TYPE |
| -minsert-sched-nops=SCHEME |
| -mcall-sysv -mcall-netbsd |
| -maix-struct-return -msvr4-struct-return |
| -mabi=ABI-TYPE -msecure-plt -mbss-plt |
| -mblock-move-inline-limit=NUM |
| -misel -mno-isel |
| -misel=yes -misel=no |
| -mspe -mno-spe |
| -mspe=yes -mspe=no |
| -mpaired |
| -mgen-cell-microcode -mwarn-cell-microcode |
| -mvrsave -mno-vrsave |
| -mmulhw -mno-mulhw |
| -mdlmzb -mno-dlmzb |
| -mfloat-gprs=yes -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double |
| -mprototype -mno-prototype |
| -msim -mmvme -mads -myellowknife -memb -msdata |
| -msdata=OPT -mvxworks -G NUM -pthread |
| -mrecip -mrecip=OPT -mno-recip -mrecip-precision |
| -mno-recip-precision |
| -mveclibabi=TYPE -mfriz -mno-friz |
| |
| _RX Options_ |
| -m64bit-doubles -m32bit-doubles -fpu -nofpu |
| -mcpu= |
| -mbig-endian-data -mlittle-endian-data |
| -msmall-data |
| -msim -mno-sim |
| -mas100-syntax -mno-as100-syntax |
| -mrelax |
| -mmax-constant-size= |
| -mint-register= |
| -msave-acc-in-interrupts |
| |
| _S/390 and zSeries Options_ |
| -mtune=CPU-TYPE -march=CPU-TYPE |
| -mhard-float -msoft-float -mhard-dfp -mno-hard-dfp |
| -mlong-double-64 -mlong-double-128 |
| -mbackchain -mno-backchain -mpacked-stack -mno-packed-stack |
| -msmall-exec -mno-small-exec -mmvcle -mno-mvcle |
| -m64 -m31 -mdebug -mno-debug -mesa -mzarch |
| -mtpf-trace -mno-tpf-trace -mfused-madd -mno-fused-madd |
| -mwarn-framesize -mwarn-dynamicstack -mstack-size -mstack-guard |
| |
| _Score Options_ |
| -meb -mel |
| -mnhwloop |
| -muls |
| -mmac |
| -mscore5 -mscore5u -mscore7 -mscore7d |
| |
| _SH Options_ |
| -m1 -m2 -m2e |
| -m2a-nofpu -m2a-single-only -m2a-single -m2a |
| -m3 -m3e |
| -m4-nofpu -m4-single-only -m4-single -m4 |
| -m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al |
| -m5-64media -m5-64media-nofpu |
| -m5-32media -m5-32media-nofpu |
| -m5-compact -m5-compact-nofpu |
| -mb -ml -mdalign -mrelax |
| -mbigtable -mfmovd -mhitachi -mrenesas -mno-renesas -mnomacsave |
| -mieee -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 |
| -maccumulate-outgoing-args -minvalid-symbols |
| |
| _Solaris 2 Options_ |
| -mimpure-text -mno-impure-text |
| -threads -pthreads -pthread |
| |
| _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 |
| -mlittle-endian |
| -mstack-bias -mno-stack-bias |
| -munaligned-doubles -mno-unaligned-doubles |
| -mv8plus -mno-v8plus -mvis -mno-vis |
| -mfix-at697f |
| |
| _SPU Options_ |
| -mwarn-reloc -merror-reloc |
| -msafe-dma -munsafe-dma |
| -mbranch-hints |
| -msmall-mem -mlarge-mem -mstdmain |
| -mfixed-range=REGISTER-RANGE |
| -mea32 -mea64 |
| -maddress-space-conversion -mno-address-space-conversion |
| -mcache-size=CACHE-SIZE |
| -matomic-updates -mno-atomic-updates |
| |
| _System V Options_ |
| -Qy -Qn -YP,PATHS -Ym,DIR |
| |
| _V850 Options_ |
| -mlong-calls -mno-long-calls -mep -mno-ep |
| -mprolog-function -mno-prolog-function -mspace |
| -mtda=N -msda=N -mzda=N |
| -mapp-regs -mno-app-regs |
| -mdisable-callt -mno-disable-callt |
| -mv850e2v3 |
| -mv850e2 |
| -mv850e1 -mv850es |
| -mv850e |
| -mv850 -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. |
| |
| _Xstormy16 Options_ |
| -msim |
| |
| _Xtensa Options_ |
| -mconst16 -mno-const16 |
| -mfused-madd -mno-fused-madd |
| -mforce-no-pic |
| -mserialize-volatile -mno-serialize-volatile |
| -mtext-section-literals -mno-text-section-literals |
| -mtarget-align -mno-target-align |
| -mlongcalls -mno-longcalls |
| |
| _zSeries Options_ See S/390 and zSeries Options. |
| |
| _Code Generation Options_ |
| *Note Options for Code Generation Conventions: Code Gen Options. |
| -fcall-saved-REG -fcall-used-REG |
| -ffixed-REG -fexceptions |
| -fnon-call-exceptions -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 -fsplit-stack |
| -fleading-underscore -ftls-model=MODEL |
| -ftrapv -fwrapv -fbounds-check |
| -fvisibility -fstrict-volatile-bitfields |
| |
| |
| * 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. |
| |
| |
| 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 (default), or C, C++ header file to be turned |
| into an Ada spec (via the `-fdump-ada-spec' switch). |
| |
| `FILE.cc' |
| `FILE.cp' |
| `FILE.cxx' |
| `FILE.cpp' |
| `FILE.CPP' |
| `FILE.c++' |
| `FILE.C' |
| C++ source code 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 or Ada spec. |
| |
| `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.go' |
| Go source code. |
| |
| `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 cpp-output |
| c++ c++-header c++-cpp-output |
| objective-c objective-c-header objective-c-cpp-output |
| objective-c++ objective-c++-header objective-c++-cpp-output |
| assembler assembler-with-cpp |
| ada |
| f77 f77-cpp-input f95 f95-cpp-input |
| go |
| java |
| |
| `-x none' |
| Turn off any specification of a language, so that subsequent files |
| are handled according to their file name suffixes (as they are if |
| `-x' has not been used at all). |
| |
| `-pass-exit-codes' |
| Normally the `gcc' program 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 arguments are |
| quoted unless they contain only alphanumeric characters or `./-_'. |
| This is useful for shell scripts to capture the driver-generated |
| command lines. |
| |
| `-pipe' |
| Use pipes rather than temporary files for communication between the |
| various stages of compilation. This fails to work on some systems |
| where the assembler is unable to read from a pipe; but the GNU |
| assembler has no trouble. |
| |
| `--help' |
| Print (on the standard output) a description of the command line |
| options understood by `gcc'. If the `-v' option is also specified |
| then `--help' 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 |
| |
| `-canonical-prefixes' |
| Always expand any symbolic links, resolve references to `/../' or |
| `/./', and make the path absolute when generating a relative |
| prefix. |
| |
| `-no-canonical-prefixes' |
| Never expand any symbolic links, resolve references to `/../' or |
| `/./', or make the path absolute when generating a relative |
| prefix. If neither `-canonical-prefixes' nor |
| `-nocanonical-prefixes' is given, GCC tries to set an appropriate |
| default by looking for a target-specific subdirectory alongside the |
| directory containing the compiler driver. |
| |
| `--version' |
| Display the version number and copyrights of the invoked GCC. |
| |
| `-wrapper' |
| Invoke all subcommands under a wrapper program. The name of the |
| wrapper program and its parameters are passed as a comma separated |
| list. |
| |
| gcc -c t.c -wrapper gdb,--args |
| |
| This will invoke all subprograms of `gcc' under `gdb --args', thus |
| the invocation of `cc1' will be `gdb --args cc1 ...'. |
| |
| `-fplugin=NAME.so' |
| Load the plugin code in file NAME.so, assumed to be a shared |
| object to be dlopen'd by the compiler. The base name of the |
| shared object file is used to identify the plugin for the purposes |
| of argument parsing (See `-fplugin-arg-NAME-KEY=VALUE' below). |
| Each plugin should define the callback functions specified in the |
| Plugins API. |
| |
| `-fplugin-arg-NAME-KEY=VALUE' |
| Define an argument called KEY with a value of VALUE for the plugin |
| called NAME. |
| |
| `-fdump-ada-spec[-slim]' |
| For C and C++ source and include files, generate corresponding Ada |
| specs. *Note Generating Ada Bindings for C and C++ headers: |
| (gnat_ugn)Generating Ada Bindings for C and C++ headers, which |
| provides detailed documentation on this feature. |
| |
| `-fdump-go-spec=FILE' |
| For input files in any language, generate corresponding Go |
| declarations in FILE. This generates Go `const', `type', `var', |
| and `func' declarations which may be a useful way to start writing |
| a Go interface to code written in some other language. |
| |
| `@FILE' |
| Read command-line options from FILE. The options read are |
| inserted in place of the original @FILE option. If FILE does not |
| exist, or cannot be read, then the option will be treated |
| literally, and not removed. |
| |
| Options in FILE are separated by whitespace. A whitespace |
| character may be included in an option by surrounding the entire |
| option in either single or double quotes. Any character |
| (including a backslash) may be included by prefixing the character |
| to be included with a backslash. The FILE may itself contain |
| additional @FILE options; any such options will be processed |
| recursively. |
| |
| |
| File: gcc.info, Node: Invoking G++, Next: C Dialect Options, Prev: Overall Options, Up: Invoking GCC |
| |
| 3.3 Compiling C++ Programs |
| ========================== |
| |
| C++ source files conventionally use one of the suffixes `.C', `.cc', |
| `.cpp', `.CPP', `.c++', `.cp', or `.cxx'; C++ header files often use |
| `.hh', `.hpp', `.H', or (for shared template code) `.tcc'; and |
| preprocessed C++ files use the suffix `.ii'. GCC recognizes files with |
| these names and compiles them as C++ programs even if you call the |
| compiler the same way as for compiling C programs (usually with the |
| name `gcc'). |
| |
| However, the use of `gcc' does not add the C++ library. `g++' is a |
| program that calls GCC and 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. |
| |
| |
| File: gcc.info, Node: C Dialect Options, Next: C++ Dialect Options, Prev: Invoking G++, Up: Invoking GCC |
| |
| 3.4 Options Controlling C Dialect |
| ================================= |
| |
| The following options control the dialect of C (or languages derived |
| from C, such as C++, Objective-C and Objective-C++) that the compiler |
| accepts: |
| |
| `-ansi' |
| In C mode, this is equivalent to `-std=c90'. In C++ mode, it is |
| equivalent to `-std=c++98'. |
| |
| This turns off certain features of GCC that are incompatible with |
| ISO C90 (when compiling C code), or of standard C++ (when |
| compiling C++ code), such as the `asm' and `typeof' keywords, and |
| predefined macros such as `unix' and `vax' that identify the type |
| of system you are using. It also enables the undesirable and |
| rarely used ISO trigraph feature. For the C compiler, it disables |
| recognition of C++ style `//' comments as well as the `inline' |
| keyword. |
| |
| The alternate keywords `__asm__', `__extension__', `__inline__' |
| and `__typeof__' continue to work despite `-ansi'. You would not |
| want to use them in an ISO C program, of course, but it is useful |
| to put them in header files that might be included in compilations |
| done with `-ansi'. Alternate predefined macros such as `__unix__' |
| and `__vax__' are also available, with or without `-ansi'. |
| |
| The `-ansi' option does not cause non-ISO programs to be rejected |
| gratuitously. For that, `-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 `c90' or |
| `c++98', and GNU dialects of those standards, such as `gnu90' 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=c90' |
| turns off certain features of GCC that are incompatible with ISO |
| C90, such as the `asm' and `typeof' keywords, but not other GNU |
| extensions that do not have a meaning in ISO C90, such as omitting |
| the middle term of a `?:' expression. On the other hand, 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=gnu90 -pedantic' would warn about |
| C++ style `//' comments, while `-std=gnu99 -pedantic' would not. |
| |
| A value for this option must be provided; possible values are |
| |
| `c90' |
| `c89' |
| `iso9899:1990' |
| Support all ISO C90 programs (certain GNU extensions that |
| conflict with ISO C90 are disabled). Same as `-ansi' for C |
| code. |
| |
| `iso9899:199409' |
| ISO C90 as modified in amendment 1. |
| |
| `c99' |
| `c9x' |
| `iso9899:1999' |
| `iso9899:199x' |
| ISO C99. Note that this standard is not yet fully supported; |
| see `http://gcc.gnu.org/gcc-4.6/c99status.html' for more |
| information. The names `c9x' and `iso9899:199x' are |
| deprecated. |
| |
| `c1x' |
| ISO C1X, the draft of the next revision of the ISO C standard. |
| Support is limited and experimental and features enabled by |
| this option may be changed or removed if changed in or |
| removed from the standard draft. |
| |
| `gnu90' |
| `gnu89' |
| GNU dialect of ISO C90 (including some C99 features). This is |
| the default for C code. |
| |
| `gnu99' |
| `gnu9x' |
| GNU dialect of ISO C99. When ISO C99 is fully implemented in |
| GCC, this will become the default. The name `gnu9x' is |
| deprecated. |
| |
| `gnu1x' |
| GNU dialect of ISO C1X. Support is limited and experimental |
| and features enabled by this option may be changed or removed |
| if changed in or removed from the standard draft. |
| |
| `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 `-std=c90' or |
| `-std=gnu90' mode. |
| |
| The preprocessor macros `__GNUC_GNU_INLINE__' and |
| `__GNUC_STDC_INLINE__' may be used to check which semantics are in |
| effect for `inline' functions. *Note 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 v3.0 `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. |
| |
| In C++ code, this allows member names in structures to be similar |
| to previous types declarations. |
| |
| typedef int UOW; |
| struct ABC { |
| UOW UOW; |
| }; |
| |
| Some cases of unnamed fields in structures and unions are only |
| accepted with this option. *Note Unnamed struct/union fields |
| within structs/unions: Unnamed Fields, for details. |
| |
| `-fplan9-extensions' |
| Accept some non-standard constructs used in Plan 9 code. |
| |
| This enables `-fms-extensions', permits passing pointers to |
| structures with anonymous fields to functions which expect |
| pointers to elements of the type of the field, and permits |
| referring to anonymous fields declared using a typedef. *Note |
| Unnamed struct/union fields within structs/unions: Unnamed Fields, |
| for details. This is only supported for C, not C++. |
| |
| `-trigraphs' |
| Support ISO C trigraphs. The `-ansi' option (and `-std' options |
| for strict ISO C conformance) implies `-trigraphs'. |
| |
| `-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. |
| |
| |
| 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. |
| |
| Version 3 corrects an error in mangling a constant address as a |
| template argument. |
| |
| Version 4 implements a standard mangling for vector types. |
| |
| Version 5 corrects the mangling of attribute const/volatile on |
| function pointer types, decltype of a plain decl, and use of a |
| function parameter in the declaration of another parameter. |
| |
| See also `-Wabi'. |
| |
| `-fno-access-control' |
| Turn off all access checking. This switch is mainly useful for |
| working around bugs in the access control code. |
| |
| `-fcheck-new' |
| Check that the pointer returned by `operator new' is non-null |
| before attempting to modify the storage allocated. This check is |
| normally unnecessary because the C++ standard specifies that |
| `operator new' 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. |
| |
| `-fconstexpr-depth=N' |
| Set the maximum nested evaluation depth for C++0x constexpr |
| functions to N. A limit is needed to detect endless recursion |
| during constant expression evaluation. The minimum specified by |
| the standard is 512. |
| |
| `-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. |
| |
| `-fnothrow-opt' |
| Treat a `throw()' exception specification as though it were a |
| `noexcept' specification to reduce or eliminate the text size |
| overhead relative to a function with no exception specification. |
| If the function has local variables of types with non-trivial |
| destructors, the exception specification will actually make the |
| function smaller because the EH cleanups for those variables can be |
| optimized away. The semantic effect is that an exception thrown |
| out of a function with such an exception specification will result |
| in a call to `terminate' rather than `unexpected'. |
| |
| `-fno-operator-names' |
| Do not treat the operator name keywords `and', `bitand', `bitor', |
| `compl', `not', `or' and `xor' as synonyms as keywords. |
| |
| `-fno-optional-diags' |
| Disable diagnostics that the standard says a compiler does not |
| need to issue. Currently, the only such diagnostic issued by G++ |
| is the one for a name having multiple meanings within a class. |
| |
| `-fpermissive' |
| Downgrade some diagnostics about nonconformant code from errors to |
| warnings. Thus, using `-fpermissive' will allow some |
| nonconforming code to compile. |
| |
| `-fno-pretty-templates' |
| When an error message refers to a specialization of a function |
| template, the compiler will normally print the signature of the |
| template followed by the template arguments and any typedefs or |
| typenames in the signature (e.g. `void f(T) [with T = int]' rather |
| than `void f(int)') so that it's clear which template is involved. |
| When an error message refers to a specialization of a class |
| template, the compiler will omit any template arguments which match |
| the default template arguments for that template. If either of |
| these behaviors make it harder to understand the error message |
| rather than easier, using `-fno-pretty-templates' will disable |
| them. |
| |
| `-frepo' |
| Enable automatic template instantiation at link time. This option |
| also implies `-fno-implicit-templates'. *Note Template |
| Instantiation::, for more information. |
| |
| `-fno-rtti' |
| Disable generation of information about every class with virtual |
| functions for use by the C++ 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. |
| |
| `-fstrict-enums' |
| Allow the compiler to optimize using the assumption that a value of |
| enumeration type can only be one of the values of the enumeration |
| (as defined in the C++ standard; basically, a value which can be |
| represented in the minimum number of bits needed to represent all |
| the enumerators). This assumption may not be valid if the program |
| uses a cast to convert an arbitrary integer value to the |
| enumeration type. |
| |
| `-ftemplate-depth=N' |
| Set the maximum instantiation depth for template classes to N. A |
| limit on the template instantiation depth is needed to detect |
| endless recursions during template class instantiation. ANSI/ISO |
| C++ conforming programs must not rely on a maximum depth greater |
| than 17 (changed to 1024 in C++0x). |
| |
| `-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 in `-fabi-version=2' (the default) |
| include: |
| |
| * A template with a non-type template parameter of reference |
| type is mangled incorrectly: |
| extern int N; |
| template <int &> struct S {}; |
| void n (S<N>) {2} |
| |
| This is fixed in `-fabi-version=3'. |
| |
| * SIMD vector types declared using `__attribute |
| ((vector_size))' are mangled in a non-standard way that does |
| not allow for overloading of functions taking vectors of |
| different sizes. |
| |
| The mangling is changed in `-fabi-version=4'. |
| |
| The known incompatibilities in `-fabi-version=1' include: |
| |
| * Incorrect handling of tail-padding for bit-fields. G++ may |
| attempt to pack data into the same byte as a base class. For |
| example: |
| |
| struct A { virtual void f(); int f1 : 1; }; |
| struct B : public A { int f2 : 1; }; |
| |
| In this case, G++ 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. |
| |
| `-Wnoexcept (C++ and Objective-C++ only)' |
| Warn when a noexcept-expression evaluates to false because of a |
| call to a function that does not have a non-throwing exception |
| specification (i.e. `throw()' or `noexcept') but is known by the |
| compiler to never throw an exception. |
| |
| `-Wnon-virtual-dtor (C++ and Objective-C++ only)' |
| Warn when a class has virtual functions and 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 ='. |
| |
| |
| File: gcc.info, Node: Objective-C and Objective-C++ Dialect Options, Next: Language Independent Options, Prev: C++ Dialect Options, Up: Invoking GCC |
| |
| 3.6 Options Controlling Objective-C and Objective-C++ Dialects |
| ============================================================== |
| |
| (NOTE: This manual does not describe the Objective-C and Objective-C++ |
| languages themselves. *Note Language Standards Supported by GCC: |
| Standards, for references.) |
| |
| This section describes the command-line options that are only |
| meaningful for Objective-C and Objective-C++ programs, 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 (`[receiver |
| message:arg]') in this translation unit ensure that the receiver is |
| not `nil'. This allows for more efficient entry points in the |
| runtime to be used. This option is only available in conjunction |
| with the NeXT runtime and ABI version 0 or 1. |
| |
| `-fobjc-abi-version=N' |
| Use version N of the Objective-C ABI for the selected runtime. |
| This option is currently supported only for the NeXT runtime. In |
| that case, Version 0 is the traditional (32-bit) ABI without |
| support for properties and other Objective-C 2.0 additions. |
| Version 1 is the traditional (32-bit) ABI with support for |
| properties and other Objective-C 2.0 additions. Version 2 is the |
| modern (64-bit) ABI. If nothing is specified, the default is |
| Version 0 on 32-bit target machines, and Version 2 on 64-bit |
| target machines. |
| |
| `-fobjc-call-cxx-cdtors' |
| For each Objective-C class, check if any of its instance variables |
| is a C++ object with a non-trivial default constructor. If so, |
| synthesize a special `- (id) .cxx_construct' instance method 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 `- (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 required to use the Objective-C keywords `@try', |
| `@throw', `@catch', `@finally' and `@synchronized'. This option |
| is available with both the GNU runtime and the NeXT runtime (but |
| not available in conjunction with the NeXT runtime on Mac OS X |
| 10.2 and earlier). |
| |
| `-fobjc-gc' |
| Enable garbage collection (GC) in Objective-C and Objective-C++ |
| programs. This option is only available with the NeXT runtime; the |
| GNU runtime has a different garbage collection implementation that |
| does not require special compiler flags. |
| |
| `-fobjc-nilcheck' |
| For the NeXT runtime with version 2 of the ABI, check for a nil |
| receiver in method invocations before doing the actual method call. |
| This is the default and can be disabled using |
| `-fno-objc-nilcheck'. Class methods and super calls are never |
| checked for nil in this way no matter what this flag is set to. |
| Currently this flag does nothing when the GNU runtime, or an older |
| version of the NeXT runtime ABI, is used. |
| |
| `-fobjc-std=objc1' |
| Conform to the language syntax of Objective-C 1.0, the language |
| recognized by GCC 4.0. This only affects the Objective-C |
| additions to the C/C++ language; it does not affect conformance to |
| C/C++ standards, which is controlled by the separate C/C++ dialect |
| option flags. When this option is used with the Objective-C or |
| Objective-C++ compiler, any Objective-C syntax that is not |
| recognized by GCC 4.0 is rejected. This is useful if you need to |
| make sure that your Objective-C code can be compiled with older |
| versions of GCC. |
| |
| `-freplace-objc-classes' |
| Emit a special marker instructing `ld(1)' not to statically link in |
| the resulting object file, and allow `dyld(1)' to load it in at |
| run time instead. This is used in conjunction with the |
| Fix-and-Continue debugging mode, where the object file in question |
| may be recompiled and dynamically reloaded in the course of |
| program execution, without the need to restart the program itself. |
| Currently, Fix-and-Continue functionality is only available in |
| conjunction with the NeXT runtime on Mac OS X 10.3 and later. |
| |
| `-fzero-link' |
| When compiling for the NeXT runtime, the compiler ordinarily |
| replaces calls to `objc_getClass("...")' (when the name of the |
| class is known at compile time) with static class references that |
| get initialized at load time, which improves run-time performance. |
| Specifying the `-fzero-link' flag suppresses this behavior and |
| causes calls to `objc_getClass("...")' to be retained. This is |
| useful in Zero-Link debugging mode, since it allows for individual |
| class implementations to be modified during program execution. |
| The GNU runtime currently always retains calls to |
| `objc_get_class("...")' regardless of command line options. |
| |
| `-gen-decls' |
| Dump interface declarations for all classes seen in the source |
| file to a file named `SOURCENAME.decl'. |
| |
| `-Wassign-intercept (Objective-C and Objective-C++ only)' |
| Warn whenever an Objective-C assignment is being intercepted by the |
| garbage collector. |
| |
| `-Wno-protocol (Objective-C and Objective-C++ only)' |
| If a class is declared to implement a protocol, a warning is |
| issued for every method in the protocol that is not implemented by |
| the class. The default behavior is to issue a warning for every |
| method not explicitly implemented in the class, even if a method |
| implementation is inherited from the superclass. If you use the |
| `-Wno-protocol' option, then methods inherited from the superclass |
| are considered to be implemented, and no warning is issued for |
| them. |
| |
| `-Wselector (Objective-C and Objective-C++ only)' |
| Warn if multiple methods of different types for the same selector |
| are found during compilation. The check is performed on the list |
| of methods in the final stage of compilation. Additionally, a |
| check is performed for each selector appearing in a |
| `@selector(...)' expression, and a corresponding method for that |
| selector has been found during compilation. Because these checks |
| scan the method table only at the end of compilation, these |
| warnings are not produced if the final stage of compilation is not |
| reached, for example because an error is found during compilation, |
| or because the `-fsyntax-only' option is being used. |
| |
| `-Wstrict-selector-match (Objective-C and Objective-C++ only)' |
| Warn if multiple methods with differing argument and/or return |
| types are found for a given selector when attempting to send a |
| message using this selector to a receiver of type `id' or `Class'. |
| When this flag is off (which is the default behavior), the |
| compiler 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. |
| |
| |
| |
| 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. |
| |
| `-fno-diagnostics-show-option' |
| By default, each diagnostic emitted includes text which indicates |
| the command line option that directly controls the diagnostic (if |
| such an option is known to the diagnostic machinery). Specifying |
| the `-fno-diagnostics-show-option' flag suppresses that behavior. |
| |
| `-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, this warning is enabled |
| and is treated as an error. `-Wno-coverage-mismatch' can be used |
| to disable the warning or `-Wno-error=coverage-mismatch' can be |
| used to disable the error. Disable the error for this warning can |
| result in poorly optimized code, so disabling the error is useful |
| only in the case of very minor changes such as bug fixes to an |
| existing code-base. Completely disabling the warning is not |
| recommended. |
| |
| |
| |
| 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. |
| |
| `-fmax-errors=N' |
| Limits the maximum number of error messages to N, at which point |
| GCC bails out rather than attempting to continue processing the |
| source code. If N is 0 (the default), there is no limit on the |
| number of error messages produced. If `-Wfatal-errors' is also |
| specified, then `-Wfatal-errors' takes precedence over this option. |
| |
| `-w' |
| Inhibit all warning messages. |
| |
| `-Werror' |
| Make all warnings into errors. |
| |
| `-Werror=' |
| Make the specified warning into an error. The specifier for a |
| warning is appended, for example `-Werror=switch' turns the |
| warnings controlled by `-Wswitch' into errors. This switch takes a |
| negative form, to be used to negate `-Werror' for specific |
| warnings, for example `-Wno-error=switch' makes `-Wswitch' |
| warnings not be errors, even when `-Werror' is in effect. |
| |
| The warning message for each controllable warning includes the |
| option which controls the warning. That option can then be used |
| with `-Werror=' and `-Wno-error=' as described above. (Printing |
| of the option in the warning message can be disabled using the |
| `-fno-diagnostics-show-option' flag.) |
| |
| Note that specifying `-Werror='FOO automatically implies `-W'FOO. |
| However, `-Wno-error='FOO does not imply anything. |
| |
| `-Wfatal-errors' |
| This option causes the compiler to abort compilation on the first |
| error occurred rather than trying to keep going and printing |
| further error messages. |
| |
| |
| You can request many specific warnings with options beginning `-W', |
| for example `-Wimplicit' to request warnings on implicit declarations. |
| Each of these specific warning options also has a negative form |
| beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'. |
| This manual lists only one of the two forms, whichever is not the |
| default. For further, language-specific options also refer to *note |
| C++ Dialect Options:: and *note Objective-C and Objective-C++ Dialect |
| Options::. |
| |
| When an unrecognized warning option is requested (e.g., |
| `-Wunknown-warning'), GCC will emit a diagnostic stating that the |
| option is not recognized. However, if the `-Wno-' form is used, the |
| behavior is slightly different: No diagnostic will be produced for |
| `-Wno-unknown-warning' unless other diagnostics are being produced. |
| This allows the use of new `-Wno-' options with old compilers, but if |
| something goes wrong, the compiler will warn that an unrecognized |
| option was used. |
| |
| `-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 `gnu90' 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 |
| -Wenum-compare (in C/Objc; this is on by default in C++) |
| -Wimplicit-int (C and Objective-C only) |
| -Wimplicit-function-declaration (C and Objective-C only) |
| -Wcomment |
| -Wformat |
| -Wmain (only for C/ObjC and unless `-ffreestanding') |
| -Wmaybe-uninitialized |
| -Wmissing-braces |
| -Wnonnull |
| -Wparentheses |
| -Wpointer-sign |
| -Wreorder |
| -Wreturn-type |
| -Wripa-opt-mismatch |
| -Wsequence-point |
| -Wsign-compare (only in C++) |
| -Wstrict-aliasing |
| -Wstrict-overflow=1 |
| -Wswitch |
| -Wtrigraphs |
| -Wuninitialized |
| -Wunknown-pragmas |
| -Wunused-function |
| -Wunused-label |
| -Wunused-value |
| -Wunused-variable |
| -Wvolatile-register-var |
| |
| Note that some warning flags are not implied by `-Wall'. Some of |
| them warn about constructions that users generally do not consider |
| questionable, but which occasionally you might wish to check for; |
| others warn about constructions that are necessary or hard to |
| avoid in some cases, and there is no simple way to modify the code |
| to suppress the warning. Some of them are enabled by `-Wextra' but |
| many of them must be enabled individually. |
| |
| `-Wextra' |
| This enables some extra warning flags that are not enabled by |
| `-Wall'. (This option used to be called `-W'. The older name is |
| still supported, but the newer name is more descriptive.) |
| |
| -Wclobbered |
| -Wempty-body |
| -Wignored-qualifiers |
| -Wmissing-field-initializers |
| -Wmissing-parameter-type (C only) |
| -Wold-style-declaration (C only) |
| -Woverride-init |
| -Wsign-compare |
| -Wtype-limits |
| -Wuninitialized |
| -Wunused-parameter (only with `-Wunused' or `-Wall') |
| -Wunused-but-set-parameter (only with `-Wunused' or `-Wall') |
| |
| The option `-Wextra' also prints warning messages for the |
| following cases: |
| |
| * A pointer is compared against integer zero with `<', `<=', |
| `>', or `>='. |
| |
| * (C++ only) An enumerator and a non-enumerator both appear in a |
| conditional expression. |
| |
| * (C++ only) Ambiguous virtual bases. |
| |
| * (C++ only) Subscripting an array 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'. |
| |
| `-Wno-cpp' |
| (C, Objective-C, C++, Objective-C++ and Fortran only) |
| |
| Suppress warning messages emitted by `#warning' directives. |
| |
| `-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)' |
| Give a warning when a value of type `float' is implicitly promoted |
| to `double'. CPUs with a 32-bit "single-precision" floating-point |
| unit implement `float' in hardware, but emulate `double' in |
| software. On such a machine, doing computations using `double' |
| values is much more expensive because of the overhead required for |
| software emulation. |
| |
| It is easy to accidentally do computations with `double' because |
| floating-point literals are implicitly of type `double'. For |
| example, in: |
| float area(float radius) |
| { |
| return 3.14159 * radius * radius; |
| } |
| the compiler will perform the entire computation with `double' |
| because the floating-point literal is a `double'. |
| |
| `-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, C++, Objective-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 (C and Objective-C only)' |
| Same as `-Wimplicit-int' and `-Wimplicit-function-declaration'. |
| This warning is enabled by `-Wall'. |
| |
| `-Wignored-qualifiers (C and C++ only)' |
| Warn if the return type of a function has a type qualifier such as |
| `const'. For ISO C such a type qualifier has no effect, since the |
| value returned by a function is not an lvalue. For C++, the |
| warning is only emitted for scalar types or `void'. ISO C |
| prohibits qualified `void' return types on function definitions, |
| so such return types always receive a warning even without this |
| option. |
| |
| This warning is also enabled by `-Wextra'. |
| |
| `-Wmain' |
| Warn if the type of `main' is suspicious. `main' should be a |
| function with external linkage, returning int, taking either zero |
| arguments, two, or three arguments of appropriate types. This |
| warning is enabled by default in C++ and is enabled by either |
| `-Wall' or `-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 (); |
| } |
| } |
| |
| Also warn for dangerous uses of the ?: with omitted middle operand |
| GNU extension. When the condition in the ?: operator is a boolean |
| expression the omitted value will be always 1. Often the user |
| expects it to be a value computed inside the conditional |
| expression instead. |
| |
| This warning is enabled by `-Wall'. |
| |
| `-Wsequence-point' |
| Warn about code that may have undefined semantics because of |
| violations of sequence point rules in the C and C++ standards. |
| |
| The C and C++ standards 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++. |
| |
| `-Wself-assign' |
| Warn about self-assignment and self-initialization. This warning |
| is intended for detecting accidental self-assignment due to typos, |
| and therefore does not warn on a statement that is semantically a |
| self-assignment after constant folding. Here is an example of what |
| will trigger a self-assign warning and what will not: |
| |
| void func() |
| { |
| int i = 2; |
| int x = x; /* warn */ |
| float f = 5.0; |
| double a[3]; |
| |
| i = i + 0; /* not warn */ |
| f = f / 1; /* not warn */ |
| a[1] = a[1]; /* warn */ |
| i += 0; /* not warn */ |
| } |
| |
| In C++ it will not warn on self-assignment of non-POD variables |
| unless `-Wself-assign-non-pod' is also enabled. |
| |
| `-Wself-assign-non-pod' |
| Warn about self-assignment of non-POD variables. This is a |
| C++-specific warning and only effective when `-Wself-assign' is |
| enabled. |
| |
| There are cases where self-assignment might be intentional. For |
| example, a C++ programmer might write code to test whether an |
| overloaded `operator=' works when the same object is assigned to |
| itself. One way to work around the self-assign warning in such |
| cases when this flag is enabled is using the functional form |
| `object.operator=(object)' instead of the assignment form `object |
| = object', as shown in the following example. |
| |
| void test_func() |
| { |
| MyType t; |
| |
| t.operator=(t); // not warn |
| t = t; // warn |
| } |
| |
| `-Wreturn-type' |
| Warn whenever a function is defined with a return-type that |
| defaults to `int'. Also warn about any `return' statement with no |
| return-value in a function whose return-type is not `void' |
| (falling off the end of the function body is considered returning |
| without a value), and about a `return' statement with an |
| expression in a function whose return-type is `void'. |
| |
| For C++, a function without return type always produces a |
| diagnostic message, even when `-Wno-return-type' is specified. |
| The only exceptions are `main' and functions defined in system |
| headers. |
| |
| This warning is enabled by `-Wall'. |
| |
| `-Wripa-opt-mismatch' |
| When doing an FDO build with `-fprofile-use' and `-fripa', warn if |
| importing an axuiliary module that was built with a different GCC |
| command line during the profile-generate phase than the primary |
| module. |
| |
| This warning is enabled by `-Wall'. |
| |
| `-Wswitch' |
| Warn whenever a `switch' statement has an index of enumerated type |
| and lacks a `case' for one or more of the named codes of that |
| enumeration. (The presence of a `default' label prevents this |
| warning.) `case' labels outside the enumeration range also |
| provoke warnings when this option is used (even if there is a |
| `default' label). This warning is enabled by `-Wall'. |
| |
| `-Wswitch-default' |
| Warn whenever a `switch' statement does not have a `default' case. |
| |
| `-Wswitch-enum' |
| Warn whenever a `switch' statement has an index of enumerated type |
| and lacks a `case' for one or more of the named codes of that |
| enumeration. `case' labels outside the enumeration range also |
| provoke warnings when this option is used. The only difference |
| between `-Wswitch' and this option is that this option gives a |
| warning about an omitted enumeration code even if there is a |
| `default' label. |
| |
| `-Wsync-nand (C and C++ only)' |
| Warn when `__sync_fetch_and_nand' and `__sync_nand_and_fetch' |
| built-in functions are used. These functions changed semantics in |
| GCC 4.4. |
| |
| `-Wthread-safety' |
| Warn about potential thread safety issues when the code is |
| annotated with thread safety attributes. |
| |
| `Wthread-unguarded-var' |
| Warn about shared variables not properly protected by locks |
| specified in the attributes. This flag is effective only with |
| `-Wthread-safety' and enabled by default. |
| |
| `Wthread-unguarded-func' |
| Warn about function calls not properly protected by locks |
| specified in the attributes. This flag is effective only with |
| `-Wthread-safety' and enabled by default. |
| |
| `Wthread-mismatched-lock-order' |
| Warn about lock acquisition order inconsistent with what specified |
| in the attributes. This flag is effective only with |
| `-Wthread-safety' and enabled by default. |
| |
| `Wthread-mismatched-lock-acq-rel' |
| Warn about mismatched lock acquisition and release. This flag is |
| effective only with `-Wthread-safety' and enabled by default. |
| |
| `Wthread-reentrant-lock' |
| Warn about a lock being acquired recursively. This flag is |
| effective only with `-Wthread-safety' and enabled by default. |
| |
| `Wthread-unsupported-lock-name' |
| Warn about uses of unsupported lock names in attributes. This flag |
| is effective only with `-Wthread-safety' and disabled by default. |
| |
| `Wthread-attr-bind-param' |
| Make the thread safety analysis try to bind the function |
| parameters used in the attributes. This flag is effective only |
| with `-Wthread-safety' and enabled by default. |
| |
| `-Wtrigraphs' |
| Warn if any trigraphs are encountered that might change the |
| meaning of the program (trigraphs within comments are not warned |
| about). This warning is enabled by `-Wall'. |
| |
| `-Wunused-but-set-parameter' |
| Warn whenever a function parameter is assigned to, but otherwise |
| unused (aside from its declaration). |
| |
| To suppress this warning use the `unused' attribute (*note |
| Variable Attributes::). |
| |
| This warning is also enabled by `-Wunused' together with `-Wextra'. |
| |
| `-Wunused-but-set-variable' |
| Warn whenever a local variable is assigned to, but otherwise unused |
| (aside from its declaration). This warning is enabled by `-Wall'. |
| |
| To suppress this warning use the `unused' attribute (*note |
| Variable Attributes::). |
| |
| This warning is also enabled by `-Wunused', which is enabled by |
| `-Wall'. |
| |
| `-Wunused-function' |
| Warn whenever a static function is declared but not defined or a |
| non-inline static function is unused. This warning is enabled by |
| `-Wall'. |
| |
| `-Wunused-label' |
| Warn whenever a label is declared but not used. This warning is |
| enabled by `-Wall'. |
| |
| To suppress this warning use the `unused' attribute (*note |
| Variable Attributes::). |
| |
| `-Wunused-parameter' |
| Warn whenever a function parameter is unused aside from its |
| declaration. |
| |
| To suppress this warning use the `unused' attribute (*note |
| Variable Attributes::). |
| |
| `-Wno-unused-result' |
| Do not warn if a caller of a function marked with attribute |
| `warn_unused_result' (*note Variable Attributes::) does not use |
| its return value. The default is `-Wunused-result'. |
| |
| `-Wunused-variable' |
| Warn whenever a local variable or non-constant static variable is |
| unused aside from its declaration. This warning is enabled by |
| `-Wall'. |
| |
| To suppress this warning use the `unused' attribute (*note |
| Variable Attributes::). |
| |
| Note that a classic way to avoid `-Wunused-variable' warning is |
| using `x = x', but that does not work with `-Wself-assign'. Use |
| `(void) x' or `static_cast<void>(x)' instead. |
| |
| `-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. |
| |
| `-Wmaybe-uninitialized' |
| For an automatic variable, if there exists a path from the function |
| entry to a use of the variable that is initialized, but there exist |
| some other paths the variable is not initialized, the compiler will |
| emit a warning if it can not prove the uninitialized paths do not |
| happen at runtime. 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. To suppress the warning, |
| the user needs to provide a default case with assert(0) or similar |
| code. |
| |
| This option also warns when a non-volatile automatic variable |
| might be changed by a call to `longjmp'. These warnings as well |
| are possible only in optimizing compilation. |
| |
| The compiler sees only the calls to `setjmp'. It cannot know |
| where `longjmp' will be called; in fact, a signal handler could |
| call it at any point in the code. As a result, you may get a |
| warning even when there is in fact no problem because `longjmp' |
| cannot in fact be called at the place 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 pun+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. |
| |
| `-Wsuggest-attribute=[pure|const|noreturn]' |
| Warn for cases where adding an attribute may be beneficial. The |
| attributes currently supported are listed below. |
| |
| `-Wsuggest-attribute=pure' |
| `-Wsuggest-attribute=const' |
| `-Wsuggest-attribute=noreturn' |
| Warn about functions which might be candidates for attributes |
| `pure', `const' or `noreturn'. The compiler only warns for |
| functions visible in other compilation units or (in the case |
| of `pure' and `const') if it cannot prove that the function |
| returns normally. A function returns normally if it doesn't |
| contain an infinite loop nor returns abnormally by throwing, |
| calling `abort()' or trapping. This analysis requires option |
| `-fipa-pure-const', which is enabled by default at `-O' and |
| higher. Higher optimization levels improve the accuracy of |
| the analysis. |
| |
| `-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. |
| |
| `-Wtrampolines' |
| Warn about trampolines generated for pointers to nested functions. |
| |
| A trampoline is a small piece of data or code that is created at |
| run time on the stack when the address of a nested function is |
| taken, and is used to call the nested function indirectly. For |
| some targets, it is made up of data only and thus requires no |
| special treatment. But, for most targets, it is made up of code |
| and thus requires the stack to be made executable in order for |
| the program to work properly. |
| |
| `-Wfloat-equal' |
| Warn if floating point values are used in equality comparisons. |
| |
| The idea behind this is that sometimes it is convenient (for the |
| programmer) to consider floating-point values as approximations to |
| infinitely precise real numbers. If you are doing this, then you |
| need to compute (by analyzing the code, or in some other way) the |
| maximum or likely maximum error that the computation introduces, |
| and allow for it when performing comparisons (and when producing |
| output, but that's a different problem). In particular, instead |
| of testing for equality, you 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 or type declaration shadows another |
| variable, parameter, type, or class member (in C++), or whenever a |
| built-in function is shadowed. Note that in C++, the compiler will |
| not warn if a local variable shadows a struct/class/enum, but will |
| warn if it shadows an explicit typedef. |
| |
| `-Wshadow-local' |
| Warn when a local variable shadows another local variable or |
| parameter. |
| |
| `-Wshadow-compatible-local' |
| Warn when a local variable shadows another local variable or |
| parameter whose type is compatible with that of the shadowing |
| variable. In C++, type compatibility here means the type of the |
| shadowing variable can be converted to that of the shadowed |
| variable. The creation of this flag (in addition to |
| `-Wshadow-local') is based on the idea that when a local variable |
| shadows another one of incompatible type, it is most likely |
| intentional, not a bug or typo, as shown in the following example: |
| |
| for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i) |
| { |
| for (int i = 0; i < N; ++i) |
| { |
| ... |
| } |
| ... |
| } |
| |
| Since the two variable `i' in the example above have incompatible |
| types, enabling only `-Wshadow-compatible-local' will not emit a |
| warning. Because their types are incompatible, if a programmer |
| accidentally uses one in place of the other, type checking will |
| catch that and emit an error or warning. So not warning (about |
| shadowing) in this case will not lead to undetected bugs. Use of |
| this flag instead of `-Wshadow-local' can possibly reduce the |
| number of warnings triggered by intentional shadowing. |
| |
| `-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 *'. |
| |
| Also warn when making a cast which introduces a type qualifier in |
| an unsafe way. For example, casting `char **' to `const char **' |
| is unsafe, as in this example: |
| |
| /* p is char ** value. */ |
| const char **q = (const char **) p; |
| /* Assignment of readonly string to const char * is OK. */ |
| *q = "string"; |
| /* Now char** pointer points to read-only memory. */ |
| **p = 'b'; |
| |
| `-Wcast-align' |
| Warn whenever a pointer is cast such that the required alignment |
| of the target is increased. For example, warn if a `char *' is |
| cast to an `int *' on machines where integers can only be accessed |
| at two- or four-byte boundaries. |
| |
| `-Wwrite-strings' |
| When compiling C, give string constants the type `const |
| char[LENGTH]' so that copying the address of one into a |
| non-`const' `char *' pointer 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 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. |
| |
| `-Wno-conversion-null (C++ and Objective-C++ only)' |
| Do not warn for conversions between `NULL' and non-pointer types. |
| `-Wconversion-null' is enabled by default. |
| |
| `-Wreal-conversion' |
| Warn for implicit type conversions from real (`double' or `float') |
| to integral values. |
| |
| `-Wempty-body' |
| Warn if an empty body occurs in an `if', `else' or `do while' |
| statement. This warning is also enabled by `-Wextra'. |
| |
| `-Wenum-compare' |
| Warn about a comparison between values of different enum types. In |
| C++ this warning is enabled by default. In C this warning is |
| enabled by `-Wall'. |
| |
| `-Wjump-misses-init (C, Objective-C only)' |
| Warn if a `goto' statement or a `switch' statement jumps forward |
| across the initialization of a variable, or jumps backward to a |
| label after the variable has been initialized. This only warns |
| about variables which are initialized when they are declared. |
| This warning is only supported for C and Objective C; in C++ this |
| sort of branch is an error in any case. |
| |
| `-Wjump-misses-init' is included in `-Wc++-compat'. It can be |
| disabled with the `-Wno-jump-misses-init' option. |
| |
| `-Wsign-compare' |
| Warn when a comparison between signed and unsigned values could |
| produce an incorrect result when the signed value is converted to |
| unsigned. This warning is also enabled by `-Wextra'; to get the |
| other warnings of `-Wextra' without this warning, use `-Wextra |
| -Wno-sign-compare'. |
| |
| `-Wsign-conversion' |
| Warn for implicit conversions that may change the sign of an |
| integer value, like assigning a signed integer expression to an |
| unsigned integer variable. An explicit cast silences the warning. |
| In C, this option is enabled also by `-Wconversion'. |
| |
| `-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-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. |
| |
| `-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' |
| Suppress warnings from casts to pointer type of an integer of a |
| different size. In C++, casting to a pointer type of smaller size |
| is an error. `Wint-to-pointer-cast' is enabled by default. |
| |
| `max-lipo-mem' |
| When importing auxiliary modules during profile-use, check current |
| memory consumption after parsing each auxiliary module. If it |
| exceeds this limit (specified in kb), don't import any more |
| auxiliary modules. Specifying a value of 0 means don't enforce |
| this limit. This parameter is only useful when using |
| `-fprofile-use' and `-fripa'. |
| |
| `-Wno-pointer-to-int-cast (C and Objective-C only)' |
| Suppress warnings from casts from a pointer to an integer type of a |
| different size. |
| |
| `-Winvalid-pch' |
| Warn if a precompiled header (*note Precompiled Headers::) is |
| found in the search path but can't be used. |
| |
| `-Wlong-long' |
| Warn if `long long' type is used. This is enabled by either |
| `-pedantic' or `-Wtraditional' in ISO C90 and C++98 modes. To |
| inhibit the warning messages, use `-Wno-long-long'. |
| |
| `-Wvariadic-macros' |
| Warn if variadic macros are used in pedantic ISO C90 mode, or the |
| GNU alternate syntax when in pedantic ISO C99 mode. This is |
| default. To inhibit the warning messages, use |
| `-Wno-variadic-macros'. |
| |
| `-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 C90, the limit was 509 characters; |
| in C99, it was raised to 4095. C++98 does not specify a normative |
| minimum maximum, so we do not diagnose overlength strings in C++. |
| |
| This option is implied by `-pedantic', and can be disabled with |
| `-Wno-overlength-strings'. |
| |
| `-Wunsuffixed-float-constants (C and Objective-C only)' |
| GCC will issue a warning for any floating constant that does not |
| have a suffix. When used together with `-Wsystem-headers' it will |
| warn about such constants in system header files. This can be |
| useful when preparing code to use with the `FLOAT_CONST_DECIMAL64' |
| pragma from the decimal floating-point extension to C99. |
| |
| |
| File: gcc.info, Node: Debugging Options, Next: Optimize Options, Prev: Warning Options, Up: Invoking GCC |
| |
| 3.9 Options for Debugging Your Program or GCC |
| ============================================= |
| |
| GCC has various special options that are used for debugging either your |
| program or GCC: |
| |
| `-g' |
| Produce debugging information in the operating system's native |
| format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this |
| debugging information. |
| |
| On most systems that use stabs format, `-g' enables use of extra |
| debugging information that only GDB can use; this extra information |
| makes debugging work better in GDB but 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-VERSION' |
| Produce debugging information in DWARF format (if that is |
| supported). This is the format used by DBX on IRIX 6. The value |
| of VERSION may be either 2, 3 or 4; the default version is 2. |
| |
| Note that with DWARF version 2 some ports require, and will always |
| use, some non-conflicting DWARF 3 extensions in the unwind tables. |
| |
| Version 4 may require GDB 7.0 and `-fvar-tracking-assignments' for |
| maximum benefit. |
| |
| `-gstrict-dwarf' |
| Disallow using extensions of later DWARF standard version than |
| selected with `-gdwarf-VERSION'. On most targets using |
| non-conflicting DWARF extensions from later standard versions is |
| allowed. |
| |
| `-gno-strict-dwarf' |
| Allow using extensions of later DWARF standard version than |
| selected with `-gdwarf-VERSION'. |
| |
| `-gvms' |
| Produce debugging information in 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 DWARF. |
| |
| `-gmlt' |
| Produce a minimal line table, with level 1 debugging information |
| plus information about inlined functions and line numbers. |
| |
| `-gtoggle' |
| Turn off generation of debug info, if leaving out this option |
| would have generated it, or turn it on at level 2 otherwise. The |
| position of this argument in the command line does not matter, it |
| takes effect after all other options are processed, and it does so |
| only once, no matter how many times it is given. This is mainly |
| intended to be used with `-fcompare-debug'. |
| |
| `-fdump-final-insns[=FILE]' |
| Dump the final internal representation (RTL) to FILE. If the |
| optional argument is omitted (or if FILE is `.'), the name of the |
| dump file will be determined by appending `.gkd' to the |
| compilation output file name. |
| |
| `-fcompare-debug[=OPTS]' |
| If no error occurs during compilation, run the compiler a second |
| time, adding OPTS and `-fcompare-debug-second' to the arguments |
| passed to the second compilation. Dump the final internal |
| representation in both compilations, and print an error if they |
| differ. |
| |
| If the equal sign is omitted, the default `-gtoggle' is used. |
| |
| The environment variable `GCC_COMPARE_DEBUG', if defined, non-empty |
| and nonzero, implicitly enables `-fcompare-debug'. If |
| `GCC_COMPARE_DEBUG' is defined to a string starting with a dash, |
| then it is used for OPTS, otherwise the default `-gtoggle' is used. |
| |
| `-fcompare-debug=', with the equal sign but without OPTS, is |
| equivalent to `-fno-compare-debug', which disables the dumping of |
| the final representation and the second compilation, preventing |
| even `GCC_COMPARE_DEBUG' from taking effect. |
| |
| To verify full coverage during `-fcompare-debug' testing, set |
| `GCC_COMPARE_DEBUG' to say `-fcompare-debug-not-overridden', which |
| GCC will reject as an invalid option in any actual compilation |
| (rather than preprocessing, assembly or linking). To get just a |
| warning, setting `GCC_COMPARE_DEBUG' to `-w%n-fcompare-debug not |
| overridden' will do. |
| |
| `-fcompare-debug-second' |
| This option is implicitly passed to the compiler for the second |
| compilation requested by `-fcompare-debug', along with options to |
| silence warnings, and omitting other options that would cause |
| side-effect compiler outputs to files or to the standard output. |
| Dump files and preserved temporary files are renamed so as to |
| contain the `.gk' additional extension during the second |
| compilation, to avoid overwriting those generated by the first. |
| |
| When this option is passed to the compiler driver, it causes the |
| _first_ compilation to be skipped, which makes it useful for little |
| other than debugging the compiler proper. |
| |
| `-feliminate-dwarf2-dups' |
| Compress 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. |
| |
| `-fenable-icf-debug' |
| Generate additional debug information to support identical code |
| folding (ICF). This option only works with DWARF version 2 or |
| higher. |
| |
| `-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. |
| |
| `-fstack-usage' |
| Makes the compiler output stack usage information for the program, |
| on a per-function basis. The filename for the dump is made by |
| appending `.su' to the AUXNAME. AUXNAME is generated from the |
| name of the output file, if explicitly specified and it is not an |
| executable, otherwise it is the basename of the source file. An |
| entry is made up of three fields: |
| |
| * The name of the function. |
| |
| * A number of bytes. |
| |
| * One or more qualifiers: `static', `dynamic', `bounded'. |
| |
| The qualifier `static' means that the function manipulates the |
| stack statically: a fixed number of bytes are allocated for the |
| frame on function entry and released on function exit; no stack |
| adjustments are otherwise made in the function. The second field |
| is this fixed number of bytes. |
| |
| The qualifier `dynamic' means that the function manipulates the |
| stack dynamically: in addition to the static allocation described |
| above, stack adjustments are made in the body of the function, for |
| example to push/pop arguments around function calls. If the |
| qualifier `bounded' is also present, the amount of these |
| adjustments is bounded at compile-time and the second field is an |
| upper bound of the total amount of stack used by the function. If |
| it is not present, the amount of these adjustments is not bounded |
| at compile-time and the second field only represents the bounded |
| part. |
| |
| `-fprofile-arcs' |
| Add code so that program flow "arcs" are instrumented. During |
| execution the program records how many times each branch and call |
| is executed and how many times it is taken or returns. When the |
| compiled program exits it saves this data to a file called |
| `AUXNAME.gcda' for each source file. The data may be used for |
| profile-directed optimizations (`-fbranch-probabilities'), or for |
| test coverage analysis (`-ftest-coverage'). Each object file's |
| AUXNAME is generated from the name of the output file, if |
| explicitly specified and it is not the final executable, otherwise |
| it is the basename of the source file. In both cases any suffix |
| is removed (e.g. `foo.gcda' for input file `dir/foo.c', or |
| `dir/foo.gcda' for output file specified as `-o dir/foo.o'). |
| *Note Cross-profiling::. |
| |
| `--coverage' |
| This option is used to compile and link code instrumented for |
| coverage analysis. The option is a synonym for `-fprofile-arcs' |
| `-ftest-coverage' (when compiling) and `-lgcov' (when linking). |
| See the documentation for those options for more details. |
| |
| * Compile the source files with `-fprofile-arcs' plus |
| optimization and code generation options. For test coverage |
| analysis, use the additional `-ftest-coverage' option. You |
| do not need to profile every source file in a program. |
| |
| * Link your object files with `-lgcov' or `-fprofile-arcs' (the |
| latter implies the former). |
| |
| * Run the program on a representative workload to generate the |
| arc profile information. This may be repeated any number of |
| times. You can run concurrent instances of your program, and |
| provided that the file system supports locking, the data |
| files will be correctly updated. Also `fork' calls are |
| detected and correctly handled (double counting will not |
| happen). |
| |
| * For profile-directed optimizations, compile the source files |
| again with the same optimization and code generation options |
| plus `-fbranch-probabilities' (*note Options that Control |
| Optimization: Optimize Options.). |
| |
| * For test coverage analysis, use `gcov' to produce human |
| readable information from the `.gcno' and `.gcda' files. |
| Refer to the `gcov' documentation for further information. |
| |
| |
| With `-fprofile-arcs', for each function of your program GCC |
| creates a program flow graph, then finds a spanning tree for the |
| graph. Only arcs that are not on the spanning tree have to be |
| instrumented: the compiler adds code to count the number of times |
| that these arcs are executed. When an arc is the only exit or |
| only entrance to a block, the instrumentation code can be added to |
| the block; otherwise, a new basic block must be created to hold |
| the instrumentation code. |
| |
| `-ftest-coverage' |
| Produce a notes file that the `gcov' code-coverage utility (*note |
| `gcov'--a Test Coverage Program: Gcov.) can use to show program |
| coverage. Each source file's note file is called `AUXNAME.gcno'. |
| Refer to the `-fprofile-arcs' option above for a description of |
| AUXNAME and instructions on how to generate test coverage data. |
| Coverage data will match the source files more closely, if you do |
| not optimize. |
| |
| `-fdbg-cnt-list' |
| Print the name and the counter upper bound for all debug counters. |
| |
| `-fdbg-cnt=COUNTER-VALUE-LIST' |
| Set the internal debug counter upper bound. COUNTER-VALUE-LIST is |
| a comma-separated list of NAME:VALUE pairs which sets the upper |
| bound of each debug counter NAME to VALUE. All debug counters |
| have the initial upper bound of UINT_MAX, thus dbg_cnt() returns |
| true always unless the upper bound is set by this option. e.g. |
| With -fdbg-cnt=dce:10,tail_call:0 dbg_cnt(dce) will return true |
| only for first 10 invocations |
| |
| `-fenable-KIND-PASS' |
| `-fdisable-KIND-PASS=RANGE-LIST' |
| This is a set of debugging options that are used to explicitly |
| disable/enable optimization passes. For compiler users, regular |
| options for enabling/disabling passes should be used instead. |
| |
| * -fdisable-ipa-PASS Disable ipa pass PASS. PASS is the pass |
| name. If the same pass is statically invoked in the compiler |
| multiple times, the pass name should be appended with a |
| sequential number starting from 1. |
| |
| * -fdisable-rtl-PASS |
| |
| * -fdisable-rtl-PASS=RANGE-LIST Disable rtl pass PASS. PASS is |
| the pass name. If the same pass is statically invoked in the |
| compiler multiple times, the pass name should be appended |
| with a sequential number starting from 1. RANGE-LIST is a |
| comma seperated list of function ranges or assembler names. |
| Each range is a number pair seperated by a colon. The range |
| is inclusive in both ends. If the range is trivial, the |
| number pair can be simplified as a single number. If the |
| function's cgraph node's UID is falling within one of the |
| specified ranges, the PASS is disabled for that function. |
| The UID is shown in the function header of a dump file, and |
| the pass names can be dumped by using option `-fdump-passes'. |
| |
| * -fdisable-tree-PASS |
| |
| * -fdisable-tree-PASS=RANGE-LIST Disable tree pass PASS. See |
| `-fdisable-rtl' for the description of option arguments. |
| |
| * -fenable-ipa-PASS Enable ipa pass PASS. PASS is the pass |
| name. If the same pass is statically invoked in the compiler |
| multiple times, the pass name should be appended with a |
| sequential number starting from 1. |
| |
| * -fenable-rtl-PASS |
| |
| * -fenable-rtl-PASS=RANGE-LIST Enable rtl pass PASS. See |
| `-fdisable-rtl' for option argument description and examples. |
| |
| * -fenable-tree-PASS |
| |
| * -fenable-tree-PASS=RANGE-LIST Enable tree pass PASS. See |
| `-fdisable-rtl' for the description of option arguments. |
| |
| |
| # disable ccp1 for all functions |
| -fdisable-tree-ccp1 |
| # disable complete unroll for function whose cgraph node uid is 1 |
| -fenable-tree-cunroll=1 |
| # disable gcse2 for functions at the following ranges [1,1], |
| # [300,400], and [400,1000] |
| # disable gcse2 for functions foo and foo2 |
| -fdisable-rtl-gcse2=foo,foo2 |
| # disable early inlining |
| -fdisable-tree-einline |
| # disable ipa inlining |
| -fdisable-ipa-inline |
| # enable tree full unroll |
| -fenable-tree-unroll |
| |
| |
| `-dLETTERS' |
| `-fdump-rtl-PASS' |
| Says to make debugging dumps during compilation at times specified |
| by LETTERS. This is used for debugging the RTL-based passes of the |
| compiler. The file names for most of the dumps are made by |
| appending a pass number and a word to the DUMPNAME, and the files |
| are created in the directory of the output file. Note that the |
| pass number is computed statically as passes get registered into |
| the pass manager. Thus the numbering is not related to the |
| dynamic order of execution of passes. In particular, a pass |
| installed by a plugin could have a number over 200 even if it |
| executed quite early. DUMPNAME is generated from the name of the |
| output file, if explicitly specified and it is not an executable, |
| otherwise it is the basename of the source file. These switches |
| may have different effects when `-E' is used for preprocessing. |
| |
| Debug dumps can be enabled with a `-fdump-rtl' switch or some `-d' |
| option LETTERS. Here are the possible letters for use in PASS and |
| LETTERS, and their meanings: |
| |
| `-fdump-rtl-alignments' |
| Dump after branch alignments have been computed. |
| |
| `-fdump-rtl-asmcons' |
| Dump after fixing rtl statements that have unsatisfied in/out |
| constraints. |
| |
| `-fdump-rtl-auto_inc_dec' |
| Dump after auto-inc-dec discovery. This pass is only run on |
| architectures that have auto inc or auto dec instructions. |
| |
| `-fdump-rtl-barriers' |
| Dump after cleaning up the barrier instructions. |
| |
| `-fdump-rtl-bbpart' |
| Dump after partitioning hot and cold basic blocks. |
| |
| `-fdump-rtl-bbro' |
| Dump after block reordering. |
| |
| `-fdump-rtl-btl1' |
| `-fdump-rtl-btl2' |
| `-fdump-rtl-btl1' and `-fdump-rtl-btl2' enable dumping after |
| the two branch target load optimization passes. |
| |
| `-fdump-rtl-bypass' |
| Dump after jump bypassing and control flow optimizations. |
| |
| `-fdump-rtl-combine' |
| Dump after the RTL instruction combination pass. |
| |
| `-fdump-rtl-compgotos' |
| Dump after duplicating the computed gotos. |
| |
| `-fdump-rtl-ce1' |
| `-fdump-rtl-ce2' |
| `-fdump-rtl-ce3' |
| `-fdump-rtl-ce1', `-fdump-rtl-ce2', and `-fdump-rtl-ce3' |
| enable dumping after the three if conversion passes. |
| |
| `-fdump-rtl-cprop_hardreg' |
| Dump after hard register copy propagation. |
| |
| `-fdump-rtl-csa' |
| Dump after combining stack adjustments. |
| |
| `-fdump-rtl-cse1' |
| `-fdump-rtl-cse2' |
| `-fdump-rtl-cse1' and `-fdump-rtl-cse2' enable dumping after |
| the two common 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'. |
| |
| `-fdump-noaddr' |
| When doing debugging dumps, suppress address output. This makes |
| it more feasible to use diff on debugging dumps for compiler |
| invocations with different compiler binaries and/or different text |
| / bss / data / heap / stack / dso start locations. |
| |
| `-fdump-unnumbered' |
| When doing debugging dumps, suppress instruction numbers and |
| address output. This makes it more feasible to use diff on |
| debugging dumps for compiler invocations with different options, |
| in particular with and without `-g'. |
| |
| `-fdump-unnumbered-links' |
| When doing debugging dumps (see `-d' option above), suppress |
| instruction numbers for the links to the previous and next |
| instructions in a sequence. |
| |
| `-fdump-translation-unit (C++ only)' |
| `-fdump-translation-unit-OPTIONS (C++ only)' |
| Dump a representation of the tree structure for the entire |
| translation unit to a file. The file name is made by appending |
| `.tu' to the source file name, and the file is created in the same |
| directory as the output file. If the `-OPTIONS' form is used, |
| OPTIONS controls the details of the dump as described for the |
| `-fdump-tree' options. |
| |
| `-fdump-class-hierarchy (C++ only)' |
| `-fdump-class-hierarchy-OPTIONS (C++ only)' |
| Dump a representation of each class's hierarchy and virtual |
| function table layout to a file. The file name is made by |
| appending `.class' to the source file name, and the file is |
| created in the same directory as the output file. If the |
| `-OPTIONS' form is used, OPTIONS controls the details of the dump |
| as described for the `-fdump-tree' options. |
| |
| `-fdump-ipa-SWITCH' |
| Control the dumping at various stages of inter-procedural analysis |
| language tree to a file. The file name is generated by appending a |
| switch specific suffix to the source file name, and the file is |
| created in the same directory as the output file. The following |
| dumps are possible: |
| |
| `all' |
| Enables all inter-procedural analysis dumps. |
| |
| `cgraph' |
| Dumps information about call-graph optimization, unused |
| function removal, and inlining decisions. |
| |
| `inline' |
| Dump after function inlining. |
| |
| |
| `-fdump-passes' |
| Dump the list of optimization passes that are turned on and off by |
| the current command line options. |
| |
| `-fdump-statistics-OPTION' |
| Enable and control dumping of pass statistics in a separate file. |
| The file name is generated by appending a suffix ending in |
| `.statistics' to the source file name, and the file is created in |
| the same directory as the output file. If the `-OPTION' form is |
| used, `-stats' 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, and |
| the file is created in the same directory as the output file. 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. |
| |
| `asmname' |
| If `DECL_ASSEMBLER_NAME' has been set for a given decl, use |
| that in the dump instead of `DECL_NAME'. Its primary use is |
| ease of use working backward from mangled names in the |
| assembly file. |
| |
| `slim' |
| 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. |
| |
| `eh' |
| Enable showing the EH region number holding 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. |
| |
| `slp' |
| Dump each function after applying vectorization of basic |
| blocks. The file name is made by appending `.slp' to the |
| source file name. |
| |
| `vrp' |
| Dump each function after Value Range Propagation (VRP). The |
| file name is made by appending `.vrp' to the source file name. |
| |
| `all' |
| Enable all the available tree dumps with the flags provided |
| in this option. |
| |
| `-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, vectorizer |
| cost model information is reported. If N=4, alignment related |
| information is added to the reports. If N=5, data-references |
| related information (e.g. memory dependences, memory |
| access-patterns) is added to the reports. If N=6, 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=7, the vectorizer reports also |
| non-vectorized nested loops. If N=8, SLP related information is |
| added to the reports. For N=9, 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, `.sched1' or |
| `.sched2' respectively. However for N greater than nine, the |
| output is always printed to standard error. |
| |
| For N greater than zero, `-fsched-verbose' outputs the same |
| information as `-fdump-rtl-sched1' and `-fdump-rtl-sched2'. For N |
| greater than one, it also output basic block probabilities, |
| detailed ready list information and unit/insn info. For N greater |
| than two, it includes RTL at abort point, control-flow and regions |
| info. And for N over four, `-fsched-verbose' also includes |
| dependence info. |
| |
| `-save-temps' |
| `-save-temps=cwd' |
| Store the usual "temporary" intermediate files permanently; place |
| them in the current directory and name them based on the source |
| file. Thus, compiling `foo.c' with `-c -save-temps' 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'. |
| |
| If you invoke GCC in parallel, compiling several different source |
| files that share a common base name in different subdirectories or |
| the same source file compiled for multiple output destinations, it |
| is likely that the different parallel compilers will interfere |
| with each other, and overwrite the temporary files. For instance: |
| |
| gcc -save-temps -o outdir1/foo.o indir1/foo.c& |
| gcc -save-temps -o outdir2/foo.o indir2/foo.c& |
| |
| may result in `foo.i' and `foo.o' being written to simultaneously |
| by both compilers. |
| |
| `-save-temps=obj' |
| Store the usual "temporary" intermediate files permanently. If the |
| `-o' option is used, the temporary files are based on the object |
| file. If the `-o' option is not used, the `-save-temps=obj' |
| switch behaves like `-save-temps'. |
| |
| For example: |
| |
| gcc -save-temps=obj -c foo.c |
| gcc -save-temps=obj -c bar.c -o dir/xbar.o |
| gcc -save-temps=obj foobar.c -o dir2/yfoobar |
| |
| would create `foo.i', `foo.s', `dir/xbar.i', `dir/xbar.s', |
| `dir2/yfoobar.i', `dir2/yfoobar.s', and `dir2/yfoobar.o'. |
| |
| `-time[=FILE]' |
| Report the CPU time taken by each subprocess in the compilation |
| sequence. For C source files, this is the compiler proper and |
| assembler (plus the linker if linking is done). |
| |
| Without the specification of an output file, the output looks like |
| this: |
| |
| # cc1 0.12 0.01 |
| # as 0.00 0.01 |
| |
| The first number on each line is the "user time", that is time |
| spent executing the program itself. The second number is "system |
| time", time spent executing operating system routines on behalf of |
| the program. Both numbers are in seconds. |
| |
| With the specification of an output file, the output is appended |
| to the named file, and it looks like this: |
| |
| 0.12 0.01 cc1 OPTIONS |
| 0.00 0.01 as OPTIONS |
| |
| The "user time" and the "system time" are moved before the program |
| name, and the options passed to the program are displayed, so that |
| one can later tell what file was being compiled, and with which |
| options. |
| |
| `-fvar-tracking' |
| Run variable tracking pass. It computes where variables are |
| stored at each position in code. Better debugging information is |
| then generated (if the debugging information format supports this |
| information). |
| |
| It is enabled by default when compiling with optimization (`-Os', |
| `-O', `-O2', ...), debugging information (`-g') and the debug info |
| format supports it. |
| |
| `-fvar-tracking-assignments' |
| Annotate assignments to user variables early in the compilation and |
| attempt to carry the annotations over throughout the compilation |
| all the way to the end, in an attempt to improve debug information |
| while optimizing. Use of `-gdwarf-4' is recommended along with it. |
| |
| It can be enabled even if var-tracking is disabled, in which case |
| annotations will be created and maintained, but discarded at the |
| end. |
| |
| `-fvar-tracking-assignments-toggle' |
| Toggle `-fvar-tracking-assignments', in the same way that |
| `-gtoggle' toggles `-g'. |
| |
| `-print-file-name=LIBRARY' |
| Print the full absolute name of the library file LIBRARY that |
| would be used when linking--and don't do anything else. With this |
| option, GCC does not compile or link anything; it just prints the |
| file name. |
| |
| `-print-multi-directory' |
| Print the directory name corresponding to the multilib selected by |
| any other switches present in the command line. This directory is |
| supposed to exist in `GCC_EXEC_PREFIX'. |
| |
| `-print-multi-lib' |
| Print the mapping from multilib directory names to compiler |
| switches that enable them. The directory name is separated from |
| the switches by `;', and each switch starts with an `@' instead of |
| the `-', without spaces between multiple switches. This is |
| supposed to ease shell-processing. |
| |
| `-print-multi-os-directory' |
| Print the path to OS libraries for the selected multilib, relative |
| to some `lib' subdirectory. If OS libraries are present in the |
| `lib' subdirectory and no multilibs are used, this is usually just |
| `.', if OS libraries are present in `libSUFFIX' sibling |
| directories this prints e.g. `../lib64', `../lib' or `../lib32', |
| or if OS libraries are present in `lib/SUBDIR' subdirectories it |
| prints e.g. `amd64', `sparcv9' or `ev6'. |
| |
| `-print-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. |
| |
| |
| 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 in this section. |
| |
| Most optimizations are only enabled if an `-O' level is set on the |
| command line. Otherwise they are disabled, even if individual |
| optimization flags are specified. |
| |
| Depending on the target and how GCC was configured, a slightly |
| different set of optimizations may be enabled at each `-O' level than |
| those listed here. You can invoke GCC with `-Q --help=optimizers' to |
| find out the exact set of optimizations that are enabled at each level. |
| *Note Overall Options::, for examples. |
| |
| `-O' |
| `-O1' |
| Optimize. Optimizing compilation takes somewhat more time, and a |
| lot more memory for a large function. |
| |
| With `-O', the compiler tries to reduce code size and execution |
| time, without performing any optimizations that take a great deal |
| of compilation time. |
| |
| `-O' turns on the following optimization flags: |
| -fauto-inc-dec |
| -fcompare-elim |
| -fcprop-registers |
| -fdce |
| -fdefer-pop |
| -fdelayed-branch |
| -fdse |
| -fguess-branch-probability |
| -fif-conversion2 |
| -fif-conversion |
| -fipa-pure-const |
| -fipa-profile |
| -fipa-reference |
| -fmerge-constants |
| -fsplit-wide-types |
| -ftree-bit-ccp |
| -ftree-builtin-call-dce |
| -ftree-ccp |
| -ftree-ch |
| -ftree-copyrename |
| -ftree-dce |
| -ftree-dominator-opts |
| -ftree-dse |
| -ftree-forwprop |
| -ftree-fre |
| -ftree-phiprop |
| -ftree-sra |
| -ftree-pta |
| -ftree-ter |
| -funit-at-a-time |
| |
| `-O' also turns on `-fomit-frame-pointer' on machines where doing |
| so does not interfere with debugging. |
| |
| `-O2' |
| Optimize even more. GCC performs nearly all supported |
| optimizations that do not involve a space-speed tradeoff. As |
| compared to `-O', this option increases both compilation time and |
| the performance of the generated code. |
| |
| `-O2' turns on all optimization flags specified by `-O'. It also |
| turns on the following optimization flags: |
| -fthread-jumps |
| -falign-functions -falign-jumps |
| -falign-loops -falign-labels |
| -fcaller-saves |
| -fcrossjumping |
| -fcse-follow-jumps -fcse-skip-blocks |
| -fdelete-null-pointer-checks |
| -fdevirtualize |
| -fexpensive-optimizations |
| -fgcse -fgcse-lm |
| -finline-small-functions |
| -findirect-inlining |
| -fipa-sra |
| -foptimize-sibling-calls |
| -fpartial-inlining |
| -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', `-ftree-vectorize' and `-fipa-cp-clone' |
| options. |
| |
| `-O0' |
| Reduce compilation time and make debugging produce the expected |
| results. This is the default. |
| |
| `-Os' |
| Optimize for size. `-Os' enables all `-O2' optimizations that do |
| not typically increase code size. It also performs further |
| optimizations designed to reduce code size. |
| |
| `-Os' disables the following optimization flags: |
| -falign-functions -falign-jumps -falign-loops |
| -falign-labels -freorder-blocks -freorder-blocks-and-partition |
| -fprefetch-loop-arrays -ftree-vect-loop-version |
| |
| `-Ofast' |
| Disregard strict standards compliance. `-Ofast' enables all `-O3' |
| optimizations. It also enables optimizations that are not valid |
| for all standard compliant programs. It turns on `-ffast-math'. |
| |
| 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 `-O', |
| `-O2', `-O3', `-Os'. |
| |
| `-ffp-contract=STYLE' |
| `-ffp-contract=off' disables floating-point expression contraction. |
| `-ffp-contract=fast' enables floating-point expression contraction |
| such as forming of fused multiply-add operations if the target has |
| native support for them. `-ffp-contract=on' enables |
| floating-point expression contraction if allowed by the language |
| standard. This is currently not implemented and treated equal to |
| `-ffp-contract=off'. |
| |
| The default is `-ffp-contract=fast'. |
| |
| `-fomit-frame-pointer' |
| Don't keep the frame pointer in a register for functions that |
| don't need one. This avoids the instructions to save, set up and |
| restore frame pointers; it also makes an extra register available |
| in many functions. *It also makes debugging impossible on some |
| machines.* |
| |
| On some machines, such as the VAX, this flag has no effect, because |
| the standard calling sequence automatically handles the frame |
| pointer and nothing is saved by pretending it doesn't exist. The |
| machine-description macro `FRAME_POINTER_REQUIRED' controls |
| whether a target machine supports this flag. *Note Register |
| Usage: (gccint)Registers. |
| |
| Starting with GCC version 4.6, the default setting (when not |
| optimizing for size) for 32-bit Linux x86 and 32-bit Darwin x86 |
| targets has been changed to `-fomit-frame-pointer'. The default |
| can be reverted to `-fno-omit-frame-pointer' by configuring GCC |
| with the `--enable-frame-pointer' configure option. |
| |
| Enabled at levels `-O', `-O2', `-O3', `-Os'. |
| |
| `-foptimize-sibling-calls' |
| Optimize sibling and tail recursive calls. |
| |
| Enabled at levels `-O2', `-O3', `-Os'. |
| |
| `-fno-inline' |
| 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. |
| |
| `-fipa-sra' |
| Perform interprocedural scalar replacement of aggregates, removal |
| of unused parameters and replacement of parameters passed by |
| reference by parameters passed by value. |
| |
| Enabled at levels `-O2', `-O3' and `-Os'. |
| |
| `-finline-limit=N' |
| By default, GCC limits the size of functions that can be inlined. |
| This flag allows coarse control of this limit. N is the size of |
| functions that can be inlined in number of pseudo instructions. |
| |
| Inlining is actually controlled by a number of parameters, which |
| may be specified individually by using `--param NAME=VALUE'. The |
| `-finline-limit=N' option sets some of these parameters as follows: |
| |
| `max-inline-insns-single' |
| is set to N/2. |
| |
| `max-inline-insns-auto' |
| is set to N/2. |
| |
| See below for a documentation of the individual parameters |
| controlling inlining and for the defaults of these parameters. |
| |
| _Note:_ there may be no value to `-finline-limit' that results in |
| default behavior. |
| |
| _Note:_ pseudo instruction represents, in this particular context, |
| an abstract measurement of function's size. In no way does it |
| represent a count of assembly instructions and as such its exact |
| meaning might change from one release to an another. |
| |
| `-fno-keep-inline-dllexport' |
| This is a more fine-grained version of `-fkeep-inline-functions', |
| which applies only to functions that are declared using the |
| `dllexport' attribute or declspec (*Note Declaring Attributes of |
| Functions: Function Attributes.) |
| |
| `-fkeep-inline-functions' |
| In C, emit `static' functions that are declared `inline' into the |
| object file, even if the function has been inlined into all of its |
| callers. This switch does not affect functions using the `extern |
| inline' extension in GNU C90. In C++, emit any and all inline |
| functions into the object file. |
| |
| `-fkeep-static-consts' |
| Emit variables declared `static const' when optimization isn't |
| turned on, even if the variables aren't referenced. |
| |
| GCC enables this option by default. If you want to force the |
| compiler to check if 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' |
| Assume that programs cannot safely dereference null pointers, and |
| that no code or data element resides there. This enables simple |
| constant folding optimizations at all optimization levels. In |
| addition, other optimization passes in GCC use this flag to |
| control global dataflow analyses that eliminate useless checks for |
| null pointers; these assume that if a pointer is checked after it |
| has already been dereferenced, it cannot be null. |
| |
| Note however that in some environments this assumption is not true. |
| Use `-fno-delete-null-pointer-checks' to disable this optimization |
| for programs which depend on that behavior. |
| |
| Some targets, especially embedded ones, disable this option at all |
| levels. Otherwise it is enabled at all levels: `-O0', `-O1', |
| `-O2', `-O3', `-Os'. Passes that use the information are enabled |
| independently at different optimization levels. |
| |
| `-fdevirtualize' |
| Attempt to convert calls to virtual functions to direct calls. |
| This is done both within a procedure and interprocedurally as part |
| of indirect inlining (`-findirect-inlining') and interprocedural |
| constant propagation (`-fipa-cp'). Enabled at levels `-O2', |
| `-O3', `-Os'. |
| |
| `-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-loop-pressure' |
| Use IRA to evaluate register pressure in loops for decision to move |
| loop invariants. Usage of this option usually results in |
| generation of faster and smaller code on machines with big |
| register files (>= 32 registers) but it can slow compiler down. |
| |
| This option is enabled at level `-O3' for some targets. |
| |
| `-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'. |
| |
| `-fschedule-insns2' |
| Similar to `-fschedule-insns', but requests an additional pass of |
| instruction scheduling after register allocation has been done. |
| This is especially useful on machines with a relatively small |
| number of registers and where memory load instructions take more |
| than one cycle. |
| |
| Enabled at levels `-O2', `-O3', `-Os'. |
| |
| `-fno-sched-interblock' |
| Don't schedule instructions across basic blocks. This is normally |
| enabled by default when scheduling before register allocation, i.e. |
| with `-fschedule-insns' or at `-O2' or higher. |
| |
| `-fno-sched-spec' |
| Don't allow speculative motion of non-load instructions. This is |
| normally enabled by default when scheduling before register |
| allocation, i.e. with `-fschedule-insns' or at `-O2' or higher. |
| |
| `-fsched-pressure' |
| Enable register pressure sensitive insn scheduling before the |
| register allocation. This only makes sense when scheduling before |
| register allocation is enabled, i.e. with `-fschedule-insns' or at |
| `-O2' or higher. Usage of this option can improve the generated |
| code and decrease its size by preventing register pressure |
| increase above the number of available hard registers and as a |
| consequence register spills in the register allocation. |
| |
| `-fsched-spec-load' |
| Allow speculative motion of some load instructions. This only |
| makes sense when scheduling before register allocation, i.e. with |
| `-fschedule-insns' or at `-O2' or higher. |
| |
| `-fsched-spec-load-dangerous' |
| Allow speculative motion of more load instructions. This only |
| makes sense when scheduling before register allocation, i.e. with |
| `-fschedule-insns' or at `-O2' or higher. |
| |
| `-fsched-stalled-insns' |
| `-fsched-stalled-insns=N' |
| Define how many insns (if any) can be moved prematurely from the |
| queue of stalled insns into the ready list, during the second |
| scheduling pass. `-fno-sched-stalled-insns' means that no insns |
| 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. |
| |
| `-fsched-group-heuristic' |
| Enable the group heuristic in the scheduler. This heuristic favors |
| the instruction that belongs to a schedule group. This is enabled |
| by default when scheduling is enabled, i.e. with `-fschedule-insns' |
| or `-fschedule-insns2' or at `-O2' or higher. |
| |
| `-fsched-critical-path-heuristic' |
| Enable the critical-path heuristic in the scheduler. This |
| heuristic favors instructions on the critical path. This is |
| enabled by default when scheduling is enabled, i.e. with |
| `-fschedule-insns' or `-fschedule-insns2' or at `-O2' or higher. |
| |
| `-fsched-spec-insn-heuristic' |
| Enable the speculative instruction heuristic in the scheduler. |
| This heuristic favors speculative instructions with greater |
| dependency weakness. This is enabled by default when scheduling |
| is enabled, i.e. with `-fschedule-insns' or `-fschedule-insns2' |
| or at `-O2' or higher. |
| |
| `-fsched-rank-heuristic' |
| Enable the rank heuristic in the scheduler. This heuristic favors |
| the instruction belonging to a basic block with greater size or |
| frequency. This is enabled by default when scheduling is enabled, |
| i.e. with `-fschedule-insns' or `-fschedule-insns2' or at `-O2' |
| or higher. |
| |
| `-fsched-last-insn-heuristic' |
| Enable the last-instruction heuristic in the scheduler. This |
| heuristic favors the instruction that is less dependent on the |
| last instruction scheduled. This is enabled by default when |
| scheduling is enabled, i.e. with `-fschedule-insns' or |
| `-fschedule-insns2' or at `-O2' or higher. |
| |
| `-fsched-dep-count-heuristic' |
| Enable the dependent-count heuristic in the scheduler. This |
| heuristic favors the instruction that has more instructions |
| depending on it. This is enabled by default when scheduling is |
| enabled, i.e. with `-fschedule-insns' or `-fschedule-insns2' or |
| at `-O2' or higher. |
| |
| `-freschedule-modulo-scheduled-loops' |
| 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'. |
| |
| `-fcombine-stack-adjustments' |
| Tracks stack adjustments (pushes and pops) and stack memory |
| references and then tries to find ways to combine them. |
| |
| Enabled by default at `-O1' and higher. |
| |
| `-fconserve-stack' |
| Attempt to minimize stack usage. The compiler 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-forwprop' |
| Perform forward propagation on trees. This flag is enabled by |
| default at `-O' and higher. |
| |
| `-ftree-fre' |
| Perform full redundancy elimination (FRE) on trees. The difference |
| between FRE and PRE is that FRE only considers expressions that |
| are computed on all paths leading to the redundant computation. |
| This analysis is faster than PRE, though it exposes fewer |
| redundancies. This flag is enabled by default at `-O' and higher. |
| |
| `-ftree-phiprop' |
| Perform hoisting of loads from conditional pointers on trees. This |
| pass is enabled by default at `-O' and higher. |
| |
| `-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). It works only in whole program mode, so it requires |
| `-fwhole-program' 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 and interprocedural |
| modification and reference analysis. This option can cause |
| excessive memory and compile-time usage on large compilation |
| units. It is not enabled by default at any optimization level. |
| |
| `-fipa-profile' |
| Perform interprocedural profile propagation. The functions called |
| only from cold functions are marked as cold. Also functions |
| executed once (such as `cold', `noreturn', static constructors or |
| destructors) are identified. Cold functions and loop less parts of |
| functions executed once are then optimized for size. Enabled by |
| default at `-O' and higher. |
| |
| `-fipa-cp' |
| Perform interprocedural constant propagation. This optimization |
| analyzes the program to determine when values passed to functions |
| are constants and then optimizes accordingly. This optimization |
| can substantially increase performance if the application has |
| constants passed to functions. This flag is enabled by default at |
| `-O2', `-Os' and `-O3'. |
| |
| `-fipa-cp-clone' |
| Perform function cloning to make interprocedural constant |
| propagation stronger. When enabled, interprocedural constant |
| propagation 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 an 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-bit-ccp' |
| Perform sparse conditional bit constant propagation on trees and |
| propagate pointer alignment information. This pass only operates |
| on local scalar variables and is enabled by default at `-O' and |
| higher. It requires that `-ftree-ccp' is enabled. |
| |
| `-ftree-ccp' |
| Perform sparse conditional constant propagation (CCP) on trees. |
| This pass only operates on local scalar variables and is enabled |
| by default at `-O' and higher. |
| |
| `-ftree-switch-conversion' |
| Perform conversion of simple initializations in a switch to |
| initializations from a scalar array. This flag is enabled by |
| default at `-O2' and higher. |
| |
| `-ftree-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 loop interchange transformations on tree. Same as |
| `-floop-interchange'. To use this code transformation, GCC has to |
| be configured with `--with-ppl' and `--with-cloog' to enable the |
| Graphite loop transformation infrastructure. |
| |
| `-floop-interchange' |
| Perform loop interchange transformations on loops. Interchanging |
| two nested loops switches the inner and outer loops. For example, |
| given a loop like: |
| DO J = 1, M |
| DO I = 1, N |
| A(J, I) = A(J, I) * C |
| ENDDO |
| ENDDO |
| loop interchange 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. The strip length can be changed |
| using the `loop-block-tile-size' parameter. For example, given a |
| loop like: |
| DO I = 1, N |
| A(I) = A(I) + C |
| ENDDO |
| loop strip mining will transform the loop as if the user had |
| written: |
| DO II = 1, N, 51 |
| DO I = II, min (II + 50, N) |
| A(I) = A(I) + C |
| ENDDO |
| ENDDO |
| This optimization applies to all the languages supported by GCC |
| and is not limited to Fortran. To use this code transformation, |
| GCC has to be configured with `--with-ppl' and `--with-cloog' to |
| enable the Graphite loop transformation infrastructure. |
| |
| `-floop-block' |
| Perform loop blocking transformations on loops. Blocking strip |
| mines each loop in the loop nest such that the memory accesses of |
| the element loops fit inside caches. The strip length can be |
| changed using the `loop-block-tile-size' parameter. For example, |
| given a loop like: |
| DO I = 1, N |
| DO J = 1, M |
| A(J, I) = B(I) + C(J) |
| ENDDO |
| ENDDO |
| loop blocking will transform the loop as if the user had written: |
| DO II = 1, N, 51 |
| DO JJ = 1, M, 51 |
| DO I = II, min (II + 50, N) |
| DO J = JJ, min (JJ + 50, M) |
| A(J, I) = B(I) + C(J) |
| ENDDO |
| ENDDO |
| ENDDO |
| ENDDO |
| which can be beneficial when `M' is larger than the caches, |
| because the innermost loop 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. |
| |
| `-fgraphite-identity' |
| Enable the identity transformation for graphite. For every SCoP |
| we generate the polyhedral representation and transform it back to |
| gimple. Using `-fgraphite-identity' we can check the costs or |
| benefits of the GIMPLE -> GRAPHITE -> GIMPLE transformation. Some |
| minimal optimizations are also performed by the code generator |
| CLooG, like index splitting and dead code elimination in loops. |
| |
| `-floop-flatten' |
| Removes the loop nesting structure: transforms the loop nest into a |
| single loop. This transformation can be useful to vectorize all |
| the levels of the loop nest. |
| |
| `-floop-parallelize-all' |
| Use the Graphite data dependence analysis to identify loops that |
| can be parallelized. Parallelize all the loops that can be |
| analyzed to not contain loop carried dependences without checking |
| that it is profitable to parallelize the loops. |
| |
| `-fcheck-data-deps' |
| Compare the results of several data dependence analyzers. This |
| option is used for debugging the data dependence analyzers. |
| |
| `-ftree-loop-if-convert' |
| Attempt to transform conditional jumps in the innermost loops to |
| branch-less equivalents. The intent is to remove control-flow from |
| the innermost loops in order to improve the ability of the |
| vectorization pass to handle these loops. This is enabled by |
| default if vectorization is enabled. |
| |
| `-ftree-loop-if-convert-stores' |
| Attempt to also if-convert conditional jumps containing memory |
| writes. This transformation can be unsafe for multi-threaded |
| programs as it transforms conditional memory writes into |
| unconditional memory writes. For example, |
| for (i = 0; i < N; i++) |
| if (cond) |
| A[i] = expr; |
| would be transformed to |
| for (i = 0; i < N; i++) |
| A[i] = cond ? expr : A[i]; |
| potentially producing data races. |
| |
| `-ftree-loop-distribution' |
| Perform loop distribution. This flag can improve cache |
| performance on big loop bodies and allow further loop |
| optimizations, like parallelization or vectorization, to take |
| place. For example, the loop |
| DO I = 1, N |
| A(I) = B(I) + C |
| D(I) = E(I) * F |
| ENDDO |
| is transformed to |
| DO I = 1, N |
| A(I) = B(I) + C |
| ENDDO |
| DO I = 1, N |
| D(I) = E(I) * F |
| ENDDO |
| |
| `-ftree-loop-distribute-patterns' |
| Perform loop distribution of patterns that can be code generated |
| with calls to a library. This flag is enabled by default at `-O3'. |
| |
| This pass distributes the initialization loops and generates a |
| call to memset zero. For example, the loop |
| DO I = 1, N |
| A(I) = 0 |
| B(I) = A(I) + I |
| ENDDO |
| is transformed to |
| DO I = 1, N |
| A(I) = 0 |
| ENDDO |
| DO I = 1, N |
| B(I) = A(I) + I |
| ENDDO |
| and the initialization loop is transformed into a call to memset |
| zero. |
| |
| `-ftree-loop-im' |
| Perform loop invariant motion on trees. This pass moves only |
| invariants that 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-pta' |
| Perform function-local points-to analysis on trees. This flag is |
| enabled by default at `-O' and higher. |
| |
| `-ftree-sra' |
| Perform scalar replacement of aggregates. This pass replaces |
| structure references with scalars to prevent committing structures |
| to memory too early. This flag is enabled by default at `-O' and |
| higher. |
| |
| `-ftree-copyrename' |
| Perform copy renaming on trees. This pass attempts to rename |
| compiler temporaries to other variables at copy locations, usually |
| resulting in variable names which more closely resemble the |
| original variables. This flag is enabled by default at `-O' and |
| higher. |
| |
| `-ftree-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-slp-vectorize' |
| Perform basic block vectorization on trees. This flag is enabled |
| by default at `-O3' and when `-ftree-vectorize' is enabled. |
| |
| `-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. |
| |
| `-fpartial-inlining' |
| Inline parts of functions. This option has any effect only when |
| inlining itself is turned on by the `-finline-functions' or |
| `-finline-small-functions' options. |
| |
| Enabled at level `-O2'. |
| |
| `-fpredictive-commoning' |
| Perform predictive commoning optimization, i.e., reusing |
| computations (especially memory loads and stores) performed in |
| previous iterations of loops. |
| |
| This option is enabled at level `-O3'. |
| |
| `-fprefetch-loop-arrays' |
| If supported by the target machine, generate instructions to |
| prefetch memory to improve the performance of loops that access |
| large arrays. |
| |
| This option may generate better or worse code; results are highly |
| dependent on the structure of loops within the source code. |
| |
| Disabled at level `-Os'. |
| |
| `-fno-peephole' |
| `-fno-peephole2' |
| Disable any machine-specific peephole optimizations. The |
| difference between `-fno-peephole' and `-fno-peephole2' is in how |
| they are implemented in the compiler; some targets use one, some |
| use the other, a few use both. |
| |
| `-fpeephole' is enabled by default. `-fpeephole2' enabled at |
| levels `-O2', `-O3', `-Os'. |
| |
| `-fno-guess-branch-probability' |
| Do not guess branch probabilities using heuristics. |
| |
| GCC 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 the whole |
| program being compiled. All public functions and variables with |
| the exception of `main' and those merged by attribute |
| `externally_visible' become static functions and in effect are |
| optimized more aggressively by interprocedural optimizers. If |
| `gold' is used as the linker plugin, `externally_visible' |
| attributes are automatically added to functions (not variable yet |
| due to a current `gold' issue) that are accessed outside of LTO |
| objects according to resolution file produced by `gold'. For |
| other linkers that cannot generate resolution file, explicit |
| `externally_visible' attributes are still necessary. While this |
| option is equivalent to proper use of the `static' keyword for |
| programs consisting of a single file, in combination with option |
| `-flto' this flag can be used to compile many smaller scale |
| programs since the functions and variables become local for the |
| whole combined compilation unit, not for the single source file |
| itself. |
| |
| This option implies `-fwhole-file' for Fortran programs. |
| |
| `-flto[=N]' |
| This option runs the standard link-time optimizer. When invoked |
| with source code, it generates GIMPLE (one of GCC's internal |
| representations) and writes it to special ELF sections in the |
| object file. When the object files are linked together, all the |
| function bodies are read from these ELF sections and instantiated |
| as if they had been part of the same translation unit. |
| |
| To use the link-time optimizer, `-flto' needs to be specified at |
| compile time and during the final link. For example: |
| |
| gcc -c -O2 -flto foo.c |
| gcc -c -O2 -flto bar.c |
| gcc -o myprog -flto -O2 foo.o bar.o |
| |
| The first two invocations to GCC save a bytecode representation of |
| GIMPLE into special ELF sections inside `foo.o' and `bar.o'. The |
| final invocation reads the GIMPLE bytecode from `foo.o' and |
| `bar.o', merges the two files into a single internal image, and |
| compiles the result as usual. Since both `foo.o' and `bar.o' are |
| merged into a single image, this causes all the interprocedural |
| analyses and optimizations in GCC to work across the two files as |
| if they were a single one. This means, for example, that the |
| inliner is able to inline functions in `bar.o' into functions in |
| `foo.o' and vice-versa. |
| |
| Another (simpler) way to enable link-time optimization is: |
| |
| gcc -o myprog -flto -O2 foo.c bar.c |
| |
| The above generates bytecode for `foo.c' and `bar.c', merges them |
| together into a single GIMPLE representation and optimizes them as |
| usual to produce `myprog'. |
| |
| The only important thing to keep in mind is that to enable |
| link-time optimizations the `-flto' flag needs to be passed to |
| both the compile and the link commands. |
| |
| To make whole program optimization effective, it is necessary to |
| make certain whole program assumptions. The compiler needs to know |
| what functions and variables can be accessed by libraries and |
| runtime outside of the link-time optimized unit. When supported |
| by the linker, the linker plugin (see `-fuse-linker-plugin') |
| passes information to the compiler about used and externally |
| visible symbols. When the linker plugin is not available, |
| `-fwhole-program' should be used to allow the compiler to make |
| these assumptions, which leads to more aggressive optimization |
| decisions. |
| |
| Note that when a file is compiled with `-flto', the generated |
| object file is larger than a regular object file because it |
| contains GIMPLE bytecodes and the usual final code. This means |
| that object files with LTO information can be linked as normal |
| object files; if `-flto' is not passed to the linker, no |
| interprocedural optimizations are applied. |
| |
| Additionally, the optimization flags used to compile individual |
| files are not necessarily related to those used at link time. For |
| instance, |
| |
| gcc -c -O0 -flto foo.c |
| gcc -c -O0 -flto bar.c |
| gcc -o myprog -flto -O3 foo.o bar.o |
| |
| This produces individual object files with unoptimized assembler |
| code, but the resulting binary `myprog' is optimized at `-O3'. |
| If, instead, the final binary is generated without `-flto', then |
| `myprog' is not optimized. |
| |
| When producing the final binary with `-flto', GCC only applies |
| link-time optimizations to those files that contain bytecode. |
| Therefore, you can mix and match object files and libraries with |
| GIMPLE bytecodes and final object code. GCC automatically selects |
| which files to optimize in LTO mode and which files to link without |
| further processing. |
| |
| There are some code generation flags that GCC preserves when |
| generating bytecodes, as they need to be used during the final link |
| stage. Currently, the following options are saved into the GIMPLE |
| bytecode files: `-fPIC', `-fcommon' and all the `-m' target flags. |
| |
| At link time, these options are read in and reapplied. Note that |
| the current implementation makes no attempt to recognize |
| conflicting values for these options. If different files have |
| conflicting option values (e.g., one file is compiled with `-fPIC' |
| and another isn't), the compiler simply uses the last value read |
| from the bytecode files. It is recommended, then, that you |
| compile all the files participating in the same link with the same |
| options. |
| |
| If LTO encounters objects with C linkage declared with incompatible |
| types in separate translation units to be linked together |
| (undefined behavior according to ISO C99 6.2.7), a non-fatal |
| diagnostic may be issued. The behavior is still undefined at |
| runtime. |
| |
| Another feature of LTO is that it is possible to apply |
| interprocedural optimizations on files written in different |
| languages. This requires support in the language front end. |
| Currently, the C, C++ and Fortran front ends are capable of |
| emitting GIMPLE bytecodes, so something like this should work: |
| |
| gcc -c -flto foo.c |
| g++ -c -flto bar.cc |
| gfortran -c -flto baz.f90 |
| g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran |
| |
| Notice that the final link is done with `g++' to get the C++ |
| runtime libraries and `-lgfortran' is added to get the Fortran |
| runtime libraries. In general, when mixing languages in LTO mode, |
| you should use the same link command options as when mixing |
| languages in a regular (non-LTO) compilation; all you need to add |
| is `-flto' to all the compile and link commands. |
| |
| If object files containing GIMPLE bytecode are stored in a library |
| archive, say `libfoo.a', it is possible to extract and use them in |
| an LTO link if you are using a linker with plugin support. To |
| enable this feature, use the flag `-fuse-linker-plugin' at link |
| time: |
| |
| gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo |
| |
| With the linker plugin enabled, the linker extracts the needed |
| GIMPLE files from `libfoo.a' and passes them on to the running GCC |
| to make them part of the aggregated GIMPLE image to be optimized. |
| |
| If you are not using a linker with plugin support and/or do not |
| enable the linker plugin, then the objects inside `libfoo.a' are |
| extracted and linked as usual, but they do not participate in the |
| LTO optimization process. |
| |
| Link-time optimizations do not require the presence of the whole |
| program to operate. If the program does not require any symbols |
| to be exported, it is possible to combine `-flto' and |
| `-fwhole-program' to allow the interprocedural optimizers to use |
| more aggressive assumptions which may lead to improved |
| optimization opportunities. Use of `-fwhole-program' is not |
| needed when linker plugin is active (see `-fuse-linker-plugin'). |
| |
| The current implementation of LTO makes no attempt to generate |
| bytecode that is portable between different types of hosts. The |
| bytecode files are versioned and there is a strict version check, |
| so bytecode files generated in one version of GCC will not work |
| with an older/newer version of GCC. |
| |
| Link-time optimization does not work well with generation of |
| debugging information. Combining `-flto' with `-g' is currently |
| experimental and expected to produce wrong results. |
| |
| If you specify the optional N, the optimization and code |
| generation done at link time is executed in parallel using N |
| parallel jobs by utilizing an installed `make' program. The |
| environment variable `MAKE' may be used to override the program |
| used. The default value for N is 1. |
| |
| You can also specify `-flto=jobserver' to use GNU make's job |
| server mode to determine the number of parallel jobs. This is |
| useful when the Makefile calling GCC is already executing in |
| parallel. You must prepend a `+' to the command recipe in the |
| parent Makefile for this to work. This option likely only works |
| if `MAKE' is GNU make. |
| |
| This option is disabled by default. |
| |
| `-flto-partition=ALG' |
| Specify the partitioning algorithm used by the link-time optimizer. |
| The value is either `1to1' to specify a partitioning mirroring the |
| original source files or `balanced' to specify partitioning into |
| equally sized chunks (whenever possible). Specifying `none' as an |
| algorithm disables partitioning and streaming completely. The |
| default value is `balanced'. |
| |
| `-flto-compression-level=N' |
| This option specifies the level of compression used for |
| intermediate language written to LTO object files, and is only |
| meaningful in conjunction with LTO mode (`-flto'). Valid values |
| are 0 (no compression) to 9 (maximum compression). Values outside |
| this range are clamped to either 0 or 9. If the option is not |
| given, a default balanced compression setting is used. |
| |
| `-flto-report' |
| Prints a report with internal details on the workings of the |
| link-time optimizer. The contents of this report vary from |
| version to version. It is meant to be useful to GCC developers |
| when processing object files in LTO mode (via `-flto'). |
| |
| Disabled by default. |
| |
| `-fuse-linker-plugin' |
| Enables the use of a linker plugin during link-time optimization. |
| This option relies on the linker plugin support in linker that is |
| available in gold or in GNU ld 2.21 or newer. |
| |
| This option enables the extraction of object files with GIMPLE |
| bytecode out of library archives. This improves the quality of |
| optimization by exposing more code to the link-time optimizer. |
| This information specifies what symbols can be accessed externally |
| (by non-LTO object or during dynamic linking). Resulting code |
| quality improvements on binaries (and shared libraries that use |
| hidden visibility) are similar to `-fwhole-program'. See `-flto' |
| for a description of the effect of this flag and how to use it. |
| |
| This option is enabled by default when LTO support in GCC is |
| enabled and GCC was configured for use with a linker supporting |
| plugins (GNU ld 2.21 or newer or gold). |
| |
| `-fcompare-elim' |
| After register allocation and post-register allocation instruction |
| splitting, identify arithmetic instructions that compute processor |
| flags similar to a comparison operation based on that arithmetic. |
| If possible, eliminate the explicit comparison operation. |
| |
| This pass only applies to certain targets that cannot explicitly |
| represent the comparison operation before register allocation is |
| complete. |
| |
| Enabled at levels `-O', `-O2', `-O3', `-Os'. |
| |
| `-fuse-ld=gold' |
| Use the `gold' linker instead of the default linker. This option |
| is only necessary if GCC has been configured with `--enable-gold' |
| and `--enable-ld=default'. |
| |
| `-fuse-ld=bfd' |
| Use the `ld.bfd' linker instead of the default linker. This |
| option is only necessary if GCC has been configured with |
| `--enable-gold' and `--enable-ld'. |
| |
| `-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 for the profile data files in to PATH. |
| This option affects only the profile data generated by |
| `-fprofile-generate', `-ftest-coverage', `-fprofile-arcs' and used |
| by `-fprofile-use' and `-fbranch-probabilities' and its related |
| options. Both absolute and relative paths can be used. By |
| default, GCC 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-generate-sampling' |
| Enable sampling for instrumented binaries. Instead of recording |
| every event, record only every N-th event, where N (the sampling |
| rate) can be set either at compile time using `--param |
| profile-generate-sampling-rate=VALUE', or at execution start time |
| through environment variable `GCOV_SAMPLING_RATE'. |
| |
| At this time sampling applies only to branch counters. A sampling |
| rate of 100 decreases instrumentated binary slowdown from up to |
| 20x for heavily threaded applications down to around 2x. |
| `-fprofile-correction' is always needed with sampling. |
| |
| `-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'. |
| |
| 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'. |
| |
| `-fpmu-profile-generate=PMUOPTION' |
| Enable performance monitoring unit (PMU) profiling. This collects |
| hardware counter data corresponding to PMUOPTION. Currently only |
| LOAD-LATENCY and BRANCH-MISPREDICT are supported using pfmon tool. |
| You must use `-fpmu-profile-generate' both when compiling and when |
| linking your program. This PMU profile data may later be used by |
| the compiler during optimizations as well can be displayed using |
| coverage tool gcov. The params variable "pmu_profile_n_addresses" |
| can be used to restrict PMU data collection to only this many |
| addresses. |
| |
| `-fpmu-profile-use=PMUOPTION' |
| Enable performance monitoring unit (PMU) profiling based |
| optimizations. Currently only LOAD-LATENCY and BRANCH-MISPREDICT |
| are supported. |
| |
| `-fripa' |
| Perform dynamic inter-procedural analysis. This is used in |
| conjunction with the `-fprofile-generate' and `-fprofile-use' |
| options. During the `-fprofile-generate' phase, this flag turns |
| on some additional instrumentation code that enables dynamic |
| call-graph analysis. During the `-fprofile-use' phase, this flag |
| enables cross-module optimizations such as inlining. |
| |
| `-fripa-disallow-asm-modules' |
| During profile-gen, if this flag is enabled, and the module has |
| asm statements, arrange so that a bit recording this information |
| will be set in the profile feedback data file. During |
| profile-use, if this flag is enabled, and the same bit in auxiliary |
| module's profile feedback data is set, don't import this auxiliary |
| module. If this is the primary module, don't export it. |
| |
| `-fripa-disallow-opt-mismatch' |
| Don't import an auxiliary module, if the GCC command line options |
| used for this auxiliary module during the profile-generate stage |
| were different from those used for the primary module. Note that |
| any mismatches in warning-related options are ignored for this |
| comparison. |
| |
| `-fripa-no-promote-always-inline-func' |
| Do not promote static functions with always inline attribute in |
| LIPO compilation. |
| |
| `-fripa-verbose' |
| Enable printing of verbose information about dynamic |
| inter-procedural optimizations. This is used in conjunction with |
| the `-fripa'. |
| |
| `-fripa-peel-size-limit' |
| Limit loop peeling of non-const non-FP loops in a LIPO compilation |
| under estimates of a large code footprint. Enabled by default |
| under `-fripa'. Code size estimation and thresholds are controlled |
| by the `codesize-hotness-threshold' and |
| `unrollpeel-codesize-threshold' parameters. |
| |
| `-fripa-unroll-size-limit' |
| Limit loop unrolling of non-const non-FP loops in a LIPO |
| compilation under estimates of a large code footprint. Enabled by |
| default under `-fripa'. Code size estimation and thresholds are |
| controlled by the `codesize-hotness-threshold' and |
| `unrollpeel-codesize-threshold' parameters. |
| |
| `-fcallgraph-profiles-sections' |
| Emit call graph edge profile counts in .note.callgraph.text |
| sections. This is used in conjunction with `-fprofile-use'. A new |
| .note.callgraph.text section is created for each function. This |
| section lists every callee and the number of times it is called. |
| The params variable "note-cgraph-section-edge-threshold" can be |
| used to only list edges above a certain threshold. |
| |
| `-frecord-gcc-switches-in-elf' |
| Record the command line options in the .gnu.switches.text elf |
| section for sample based LIPO to do module grouping. |
| |
| The following options control compiler behavior regarding floating |
| point arithmetic. These options trade off between speed and |
| correctness. All must be specifically enabled. |
| |
| `-ffloat-store' |
| Do not store floating point variables in registers, and inhibit |
| other options that might change whether a floating point value is |
| taken from a register or memory. |
| |
| This option prevents undesirable excess precision on machines such |
| as the 68000 where the floating registers (of the 68881) keep more |
| precision than a `double' is supposed to have. Similarly for the |
| x86 architecture. For most programs, the excess precision does |
| only good, but a few programs rely on the precise definition of |
| IEEE floating point. Use `-ffloat-store' for such programs, after |
| modifying them to store all pertinent intermediate computations |
| into variables. |
| |
| `-fexcess-precision=STYLE' |
| This option allows further control over excess precision on |
| machines where floating-point registers have more precision than |
| the IEEE `float' and `double' types and the processor does not |
| support operations rounding to those types. By default, |
| `-fexcess-precision=fast' is in effect; this means that operations |
| are carried out in the precision of the registers and that it is |
| unpredictable when rounding to the types specified in the source |
| code takes place. When compiling C, if |
| `-fexcess-precision=standard' is specified then excess precision |
| will follow the rules specified in ISO C99; in particular, both |
| casts and assignments cause values to be rounded to their semantic |
| types (whereas `-ffloat-store' only affects assignments). This |
| option is enabled by default for C if a strict conformance option |
| such as `-std=c99' is used. |
| |
| `-fexcess-precision=standard' is not implemented for languages |
| other than C, and has no effect if `-funsafe-math-optimizations' |
| or `-ffast-math' is specified. On the x86, it also has no effect |
| if `-mfpmath=sse' or `-mfpmath=sse+387' is specified; in the |
| former case, IEEE semantics apply without excess precision, and in |
| the latter, rounding is unpredictable. |
| |
| `-ffast-math' |
| Sets `-fno-math-errno', `-funsafe-math-optimizations', |
| `-ffinite-math-only', `-fno-rounding-math', `-fno-signaling-nans' |
| and `-fcx-limited-range'. |
| |
| This option causes the preprocessor macro `__FAST_MATH__' to be |
| defined. |
| |
| This option is not turned on by any `-O' option besides `-Ofast' |
| since it can result in incorrect output for programs 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'. For Fortran the option is automatically enabled |
| when both `-fno-signed-zeros' and `-fno-trapping-math' are in |
| effect. |
| |
| The default is `-fno-associative-math'. |
| |
| `-freciprocal-math' |
| Allow the reciprocal of a value to be used instead of dividing by |
| the value if this enables optimizations. For example `x / y' can |
| be replaced with `x * (1/y)' which is useful if `(1/y)' is subject |
| to common subexpression elimination. Note that this loses |
| precision and increases the number of flops operating on the value. |
| |
| The default is `-fno-reciprocal-math'. |
| |
| `-ffinite-math-only' |
| Allow optimizations for floating-point arithmetic that assume that |
| arguments and results are not NaNs or +-Infs. |
| |
| This option is not turned on by any `-O' option since it can |
| result in incorrect output for programs 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'. |
| |
| `-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'. |
| |
| `min-mcf-cancel-iters' |
| The minimum number of iterations of negative cycle cancellation |
| during MCF profile correction before early termination. This |
| parameter is only useful when using `-fprofile-correction'. |
| |
| |
| 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 most likely |
| to take, the `REG_BR_PROB' values are used to exactly determine |
| which path is taken more often. |
| |
| `-fclone-hot-version-paths' |
| When multi-version calls are made using `__builtin_dispatch', this |
| flag enables cloning and hoisting of hot multiversioned paths. |
| |
| `-fprofile-values' |
| If combined with `-fprofile-arcs', it adds code so that some data |
| about values of expressions in the program is gathered. |
| |
| With `-fbranch-probabilities', it reads back the data gathered |
| from profiling values of expressions for usage in optimizations. |
| |
| Enabled with `-fprofile-generate' and `-fprofile-use'. |
| |
| `-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' and `-fpeel-loops'. |
| |
| `-ftracer' |
| Perform tail duplication to enlarge superblock size. This |
| transformation simplifies the control flow of the function |
| allowing other optimizations to do 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. |
| |
| `-fstack-protector-strong' |
| Like `-fstack-protector' but includes additional functions to be |
| protected - those that have local array definitions, or have |
| references to local frame addresses. |
| |
| `-fsection-anchors' |
| Try to reduce the number of symbolic address calculations by using |
| shared "anchor" symbols to address nearby objects. This |
| transformation can help to reduce the number of GOT entries and |
| GOT accesses on some targets. |
| |
| For example, the implementation of the following function `foo': |
| |
| static int a, b, c; |
| int foo (void) { return a + b + c; } |
| |
| 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: |
| |
| `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-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-insertion-ratio' |
| If the ratio of expression insertions to deletions is larger |
| than this value for any expression, then RTL PRE will insert |
| or remove the expression and thus leave partially redundant |
| computations in the instruction stream. The default value is |
| 20. |
| |
| `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 400. |
| |
| `max-inline-insns-auto' |
| When you use `-finline-functions' (included in `-O3'), a lot |
| of functions that would otherwise not be considered for |
| inlining by the compiler will be investigated. To those |
| functions, a different (more restrictive) limit compared to |
| functions declared inline can be applied. The default value |
| is 40. |
| |
| `mversn-clone-depth' |
| When using `-fclone-hot-version-paths', hot function paths |
| are multi- versioned via cloning. This parameter specifies |
| the maximum length of the call graph path that can be cloned. |
| The default value is 2. |
| |
| `num-mversn-clones' |
| When using `-fclone-hot-version-paths', hot function paths |
| are multi- versioned via cloning. This parameter specifies |
| the maximum number of functions that can be cloned. The |
| default value is 10. |
| |
| `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. |
| |
| `early-inlining-insns' |
| Specify growth that early inliner can make. In effect it |
| increases amount of inlining for code having large |
| abstraction penalty. The default value is 10. |
| |
| `max-early-inliner-iterations' |
| `max-early-inliner-iterations' |
| Limit of iterations of early inliner. This basically bounds |
| number of nested indirect calls early inliner can resolve. |
| Deeper chains are still handled by late inlining. |
| |
| `comdat-sharing-probability' |
| `comdat-sharing-probability' |
| Probability (in percent) that C++ inline function with comdat |
| visibility will be shared across multiple compilation units. |
| The default value is 20. |
| |
| `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. |
| |
| `gcse-cost-distance-ratio' |
| Scaling factor in calculation of maximum distance an |
| expression can be moved by GCSE optimizations. This is |
| currently supported only in the code hoisting pass. The |
| bigger the ratio, the more aggressive code hoisting will be |
| with simple expressions, i.e., the expressions which have cost |
| less than `gcse-unrestricted-cost'. Specifying 0 will disable |
| hoisting of simple expressions. The default value is 10. |
| |
| `gcse-unrestricted-cost' |
| Cost, roughly measured as the cost of a single typical machine |
| instruction, at which GCSE optimizations will not constrain |
| the distance an expression can travel. This is currently |
| supported only in the code hoisting pass. The lesser the |
| cost, the more aggressive code hoisting will be. Specifying |
| 0 will allow all expressions to travel unrestricted distances. |
| The default value is 3. |
| |
| `max-hoist-depth' |
| The depth of search in the dominator tree for expressions to |
| hoist. This is used to avoid quadratic behavior in hoisting |
| algorithm. The value of 0 will avoid limiting the search, |
| but may slow down compilation of huge functions. The default |
| value is 30. |
| |
| `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-peeled-insns-feedback' |
| The maximum number of insns of a completely peeled loop when |
| profile feedback is available and the loop is hot. Because of |
| the real profiles, this value may set to be larger for hot |
| loops. Its default value is 600. |
| |
| `max-once-peeled-insns' |
| The maximum number of insns of a peeled loop that rolls only |
| once. |
| |
| `max-once-peeled-insns-feedback' |
| The maximum number of insns of a peeled loop when profile |
| feedback is available and the loop is hot. Because of the |
| real profiles, this value may set to be larger for hot loops. |
| The default value is 600. |
| |
| `max-completely-peel-times' |
| The maximum number of iterations of a loop to be suitable for |
| complete peeling. |
| |
| `max-completely-peel-times-feedback' |
| The maximum number of iterations of a loop to be suitable for |
| complete peeling when profile feedback is available and the |
| loop is hot. Because of the real profiles, this value may set |
| to be larger for hot loops. Its default value is 16. |
| |
| `max-completely-peel-loop-nest-depth' |
| The maximum depth of a loop nest suitable for complete |
| peeling. |
| |
| `codesize-hotness-threshold' |
| The minimum profile count of basic blocks to look at when |
| estimating the code size footprint of the call graph in a |
| LIPO compile. |
| |
| `unrollpeel-codesize-threshold' |
| Maximum LIPO code size footprint estimate for loop unrolling |
| and 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. |
| |
| `scev-max-expr-complexity' |
| Bound on the complexity of the expressions in the scalar |
| evolutions analyzer. Complex expressions slow the analyzer. |
| |
| `omega-max-vars' |
| The maximum number of variables in an Omega constraint system. |
| The default value is 128. |
| |
| `omega-max-geqs' |
| The maximum number of inequalities in an Omega constraint |
| system. The default value is 256. |
| |
| `omega-max-eqs' |
| The maximum number of equalities in an Omega constraint |
| system. The default value is 128. |
| |
| `omega-max-wild-cards' |
| The maximum number of wildcard variables that the Omega |
| solver 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 entry block frequency of executions of |
| basic block in function given basic block needs to have to be |
| considered hot |
| |
| `max-predicted-iterations' |
| The maximum number of loop iterations we predict statically. |
| This is useful in cases where 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. |
| |
| `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. |
| |
| `min-insn-to-prefetch-ratio' |
| The minimum ratio between the number of instructions and the |
| number of prefetches to enable prefetching in a loop. |
| |
| `prefetch-min-insn-to-mem-ratio' |
| The minimum ratio between the number of instructions and the |
| number of memory references to enable prefetching in a loop. |
| |
| `use-canonical-types' |
| Whether the compiler should use the "canonical" type system. |
| By default, this should always be 1, which uses a more |
| efficient internal mechanism for comparing types in C++ and |
| Objective-C++. However, if bugs in the canonical type system |
| are causing compilation failures, set this value to 0 to |
| disable canonical types. |
| |
| `switch-conversion-max-branch-ratio' |
| Switch initialization conversion 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. |
| |
| `ira-loop-reserved-regs' |
| IRA can be used to evaluate more accurate register pressure |
| in loops for decision to move loop invariants (see `-O3'). |
| The number of available registers reserved for some other |
| purposes is described by this parameter. The default value |
| of the parameter is 2 which is minimal number of registers |
| needed for execution of typical instruction. This value is |
| the best found from numerous experiments. |
| |
| `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. |
| |
| `max-vartrack-size' |
| Sets a maximum number of hash table slots to use during |
| variable tracking dataflow analysis of any function. If this |
| limit is exceeded with variable tracking at assignments |
| enabled, analysis for that function is retried without it, |
| after removing all debug insns from the function. If the |
| limit is exceeded even without debug insns, var tracking |
| analysis is completely disabled for the function. Setting |
| the parameter to zero makes it unlimited. |
| |
| `min-nondebug-insn-uid' |
| Use uids starting at this parameter for nondebug insns. The |
| range below the parameter is reserved exclusively for debug |
| insns created by `-fvar-tracking-assignments', but debug |
| insns may get (non-overlapping) uids above it if the reserved |
| range is exhausted. |
| |
| `ipa-sra-ptr-growth-factor' |
| IPA-SRA will replace a pointer to an aggregate with one or |
| more new parameters only when their cumulative size is less |
| or equal to `ipa-sra-ptr-growth-factor' times the size of the |
| original pointer parameter. |
| |
| `graphite-max-nb-scop-params' |
| To avoid exponential effects in the Graphite loop transforms, |
| the number of parameters in a Static Control Part (SCoP) is |
| bounded. The default value is 10 parameters. A variable |
| whose value is unknown at compile time and defined outside a |
| SCoP is a parameter of the SCoP. |
| |
| `graphite-max-bbs-per-function' |
| To avoid exponential effects in the detection of SCoPs, the |
| size of the functions analyzed by Graphite is bounded. The |
| default value is 100 basic blocks. |
| |
| `loop-block-tile-size' |
| Loop blocking or strip mining transforms, enabled with |
| `-floop-block' or `-floop-strip-mine', strip mine each loop |
| in the loop nest by a given number of iterations. The strip |
| length can be changed using the `loop-block-tile-size' |
| parameter. The default value is 51 iterations. |
| |
| `devirt-type-list-size' |
| IPA-CP attempts to track all possible types passed to a |
| function's parameter in order to perform devirtualization. |
| `devirt-type-list-size' is the maximum number of types it |
| stores per a single formal parameter of a function. |
| |
| `lto-partitions' |
| Specify desired number of partitions produced during WHOPR |
| compilation. The number of partitions should exceed the |
| number of CPUs used for compilation. The default value is 32. |
| |
| `lto-minpartition' |
| Size of minimal partition for WHOPR (in estimated |
| instructions). This prevents expenses of splitting very |
| small programs into too many partitions. |
| |
| `cxx-max-namespaces-for-diagnostic-help' |
| The maximum number of namespaces to consult for suggestions |
| when C++ name lookup fails for an identifier. The default is |
| 1000. |
| |
| |
| |
| 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: |
| `c90' |
| `c89' |
| `iso9899:1990' |
| The ISO C standard from 1990. `c90' is the customary |
| shorthand for this version of the standard. |
| |
| The `-ansi' option is equivalent to `-std=c90'. |
| |
| `iso9899:199409' |
| The 1990 C standard, as amended in 1994. |
| |
| `iso9899:1999' |
| `c99' |
| `iso9899:199x' |
| `c9x' |
| The revised ISO C standard, published in December 1999. |
| Before publication, this was known as C9X. |
| |
| `c1x' |
| The next version of the ISO C standard, still under |
| development. |
| |
| `gnu90' |
| `gnu89' |
| The 1990 C standard plus GNU extensions. This is the default. |
| |
| `gnu99' |
| `gnu9x' |
| The 1999 C standard plus GNU extensions. |
| |
| `gnu1x' |
| The next version of the ISO C standard, still under |
| development, plus GNU extensions. |
| |
| `c++98' |
| The 1998 ISO C++ standard plus amendments. |
| |
| `gnu++98' |
| The same as `-std=c++98' plus GNU extensions. This is the |
| default for C++ code. |
| |
| `-I-' |
| Split the include path. Any directories specified with `-I' |
| options before `-I-' are searched only for headers requested with |
| `#include "FILE"'; they are not searched for `#include <FILE>'. |
| If additional directories are specified with `-I' options after |
| the `-I-', those directories are searched for all `#include' |
| directives. |
| |
| In addition, `-I-' inhibits the use of the directory of the current |
| file directory as the first search directory for `#include "FILE"'. |
| This option has been deprecated. |
| |
| `-nostdinc' |
| Do not search the standard system directories for header files. |
| Only the directories you have specified with `-I' options (and the |
| directory of the current file, if appropriate) are searched. |
| |
| `-nostdinc++' |
| Do not search for header files in the C++-specific standard |
| directories, but do still search the other standard directories. |
| (This option is used when building the C++ library.) |
| |
| `-include FILE' |
| Process FILE as if `#include "file"' appeared as the first line of |
| the primary source file. However, the first directory searched |
| for FILE is the preprocessor's working directory _instead of_ the |
| directory containing the main source file. If not found there, it |
| is searched for in the remainder of the `#include "..."' search |
| chain as normal. |
| |
| If multiple `-include' options are given, the files are included |
| in the order they appear on the command line. |
| |
| `-imacros FILE' |
| Exactly like `-include', except that any output produced by |
| scanning FILE is thrown away. Macros it defines remain defined. |
| This allows you to acquire all the macros from a header without |
| also processing its declarations. |
| |
| All files specified by `-imacros' are processed before all files |
| specified by `-include'. |
| |
| `-idirafter DIR' |
| Search DIR for header files, but do it _after_ all directories |
| specified with `-I' and the standard system directories have been |
| exhausted. DIR is treated as a system include directory. If DIR |
| begins with `=', then the `=' will be replaced by the sysroot |
| prefix; see `--sysroot' and `-isysroot'. |
| |
| `-iprefix PREFIX' |
| Specify PREFIX as the prefix for subsequent `-iwithprefix' |
| options. If the prefix represents a directory, you should include |
| the final `/'. |
| |
| `-iwithprefix DIR' |
| `-iwithprefixbefore DIR' |
| Append DIR to the prefix specified previously with `-iprefix', and |
| add the resulting directory to the include search path. |
| `-iwithprefixbefore' puts it in the same place `-I' would; |
| `-iwithprefix' puts it where `-idirafter' would. |
| |
| `-isysroot DIR' |
| This option is like the `--sysroot' option, but applies only to |
| header files (except for Darwin targets, where it applies to both |
| header files and libraries). See the `--sysroot' option for more |
| information. |
| |
| `-imultilib DIR' |
| Use DIR as a subdirectory of the directory containing |
| target-specific C++ headers. |
| |
| `-isystem DIR' |
| Search DIR for header files, after all directories specified by |
| `-I' but before the standard system directories. Mark it as a |
| system directory, so that it gets the same special treatment as is |
| applied to the standard system directories. If DIR begins with |
| `=', then the `=' will be replaced by the sysroot prefix; see |
| `--sysroot' and `-isysroot'. |
| |
| `-iquote DIR' |
| Search DIR only for header files requested with `#include "FILE"'; |
| they are not searched for `#include <FILE>', before all |
| directories specified by `-I' and before the standard system |
| directories. If DIR begins with `=', then the `=' will be replaced |
| by the sysroot prefix; see `--sysroot' and `-isysroot'. |
| |
| `-fdirectives-only' |
| When preprocessing, handle directives, but do not expand macros. |
| |
| The option's behavior depends on the `-E' and `-fpreprocessed' |
| options. |
| |
| With `-E', preprocessing is limited to the handling of directives |
| such as `#define', `#ifdef', and `#error'. Other preprocessor |
| operations, such as macro expansion and trigraph conversion are |
| not performed. In addition, the `-dD' option is implicitly |
| enabled. |
| |
| With `-fpreprocessed', predefinition of command line and most |
| builtin macros is disabled. Macros such as `__LINE__', which are |
| contextually dependent, are handled normally. This enables |
| compilation of files previously preprocessed with `-E |
| -fdirectives-only'. |
| |
| With both `-E' and `-fpreprocessed', the rules for |
| `-fpreprocessed' take precedence. This enables full preprocessing |
| of files previously preprocessed with `-E -fdirectives-only'. |
| |
| `-fdollars-in-identifiers' |
| Accept `$' in identifiers. |
| |
| `-fextended-identifiers' |
| Accept universal character names in identifiers. This option is |
| experimental; in a future version of GCC, it will be enabled by |
| default for C99 and C++. |
| |
| `-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. |
| |
| |
| 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. |
| |
| `profile-generate-sampling-rate' |
| Set the sampling rate with `-fprofile-generate-sampling'. |
| |
| |
| |
| 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, options |
| specifying linkage of the system libraries, such as |
| `-static-libgcc' or `-shared-libgcc', will be ignored. The |
| standard startup files are used normally, unless `-nostartfiles' |
| is used. The compiler may generate calls to `memcmp', `memset', |
| `memcpy' and `memmove'. These entries are usually resolved by |
| entries in libc. These entry points should be supplied through |
| some other mechanism when this option is specified. |
| |
| `-nostdlib' |
| Do not use the standard system startup files or libraries when |
| linking. No startup files and only the libraries you specify will |
| be passed to the linker, options specifying linkage of the system |
| libraries, such as `-static-libgcc' or `-shared-libgcc', will be |
| ignored. The compiler may generate calls to `memcmp', `memset', |
| `memcpy' and `memmove'. These entries are usually resolved by |
| entries in libc. These entry points should be supplied through |
| some other mechanism when this option is specified. |
| |
| One of the standard libraries bypassed by `-nostdlib' and |
| `-nodefaultlibs' is `libgcc.a', a library of internal subroutines |
| 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'. |
| |
| `-static-libstdc++' |
| When the `g++' program is used to link a C++ program, it will |
| normally automatically link against `libstdc++'. If `libstdc++' |
| is available as a shared library, and the `-static' option is not |
| used, then this will link against the shared version of |
| `libstdc++'. That is normally fine. However, it is sometimes |
| useful to freeze the version of `libstdc++' used by the program |
| without going all the way to a fully static link. The |
| `-static-libstdc++' option directs the `g++' driver to link |
| `libstdc++' statically, without necessarily linking other |
| libraries statically. |
| |
| `-symbolic' |
| Bind references to global symbols when building a shared object. |
| Warn about any unresolved references (unless overridden by the |
| link editor option `-Xlinker -z -Xlinker defs'). Only a few |
| systems support this option. |
| |
| `-T SCRIPT' |
| Use SCRIPT as the linker script. This option is supported by most |
| systems using the GNU linker. On some targets, such as bare-board |
| targets without an operating system, the `-T' option may be |
| required when linking to avoid references to undefined symbols. |
| |
| `-Xlinker OPTION' |
| Pass OPTION as an option to the linker. You can use this to |
| supply system-specific linker options 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. |
| |
| |
| 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. |
| |
| `-iplugindir=DIR' |
| Set the directory to search for plugins which are passed by |
| `-fplugin=NAME' instead of `-fplugin=PATH/NAME.so'. This option |
| is not meant to be used by the user, but only passed by the driver. |
| |
| `-iquoteDIR' |
| Add the directory DIR to the head of the list of directories to be |
| searched for header files only for the case of `#include "FILE"'; |
| they are not searched for `#include <FILE>', otherwise just like |
| `-I'. |
| |
| `-LDIR' |
| Add directory DIR to the list of directories to be searched for |
| `-l'. |
| |
| `-BPREFIX' |
| This option specifies where to find the executables, libraries, |
| include files, and data files of the compiler itself. |
| |
| The compiler driver program runs one or more of the subprograms |
| `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each |
| program it tries to run, both with and without `MACHINE/VERSION/' |
| (*note Target Options::). |
| |
| For each subprogram to be run, the compiler driver first tries the |
| `-B' prefix, if any. If that name is not found, or if `-B' 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. |
| |
| |
| 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. The current working directory is |
| included in the list of directories scanned. |
| |
| `%T' |
| Current argument is the name of a linker script. Search for that |
| file in the current list of directories to scan for libraries. If |
| the file is located insert a `--script' option into the command |
| line followed by the full path name found. If the file is not |
| found then generate an error message. Note: the current working |
| directory is not searched. |
| |
| `%eSTR' |
| Print STR as an error message. STR is terminated by a newline. |
| Use this when inconsistent options are detected. |
| |
| `%(NAME)' |
| Substitute the contents of spec string NAME at this point. |
| |
| `%[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)} |
| |
| ``remove-outfile'' |
| The `remove-outfile' spec function takes one argument. It |
| looks for the first argument in the outfiles array and |
| removes it. Here is a small example its usage: |
| |
| %:remove-outfile(-lm) |
| |
| ``pass-through-libs'' |
| The `pass-through-libs' spec function takes any number of |
| arguments. It finds any `-l' options and any non-options |
| ending in ".a" (which it assumes are the names of linker |
| input library archive files) and returns a result containing |
| all the found arguments each prepended by |
| `-plugin-opt=-pass-through=' and joined by spaces. This list |
| is intended to be passed to the LTO linker plugin. |
| |
| %:pass-through-libs(%G %L %G) |
| |
| ``print-asm-header'' |
| The `print-asm-header' function takes no arguments and simply |
| prints a banner like: |
| |
| Assembler options |
| ================= |
| |
| Use "-Wa,OPTION" to pass "OPTION" to the assembler. |
| |
| It is used to separate compiler options from assembler options |
| in the `--target-help' output. |
| |
| `%{`S'}' |
| Substitutes the `-S' switch, if that switch 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. |
| |
| `max-lipo-mem' |
| When importing auxiliary modules during profile-use, check current |
| memory consumption after parsing each auxiliary module. If it |
| exceeds this limit (specified in kb), don't import any more |
| auxiliary modules. Specifying a value of 0 means don't enforce |
| this limit. This parameter is only useful when using |
| `-fprofile-use' and `-fripa'. |
| |
| |
| The conditional text `X' in a %{`S':`X'} or similar construct may |
| contain other nested `%' constructs or spaces, or even newlines. They |
| are processed as usual, as described above. Trailing white space in |
| `X' is ignored. White space may also appear anywhere on the left side |
| of the colon in these constructs, except between `.' or `*' and the |
| corresponding word. |
| |
| The `-O', `-f', `-m', and `-W' switches are handled specifically in |
| these constructs. If another value of `-O' or the negated form of a |
| `-f', `-m', or `-W' switch is found later in the command line, the |
| earlier switch value is ignored, except with {`S'*} where `S' is just |
| one letter, which passes all matching options. |
| |
| The character `|' at the beginning of the predicate text is used to |
| indicate that a command should be piped to the following command, but |
| only if `-pipe' is specified. |
| |
| It is built into GCC which switches take arguments and which do not. |
| (You might think it would be useful to generalize this to allow each |
| compiler's spec to say which switches take arguments. But this cannot |
| be done in a consistent fashion. GCC cannot even decide which input |
| files have been specified without knowing which switches take arguments, |
| and it must know which input files to compile in order to tell which |
| compilers to run). |
| |
| GCC also knows implicitly that arguments starting in `-l' are to be |
| treated as compiler output files, and passed to the linker in their |
| proper position among the other output files. |
| |
| |
| File: gcc.info, Node: Target Options, Next: Submodel Options, Prev: Spec Files, Up: Invoking GCC |
| |
| 3.16 Specifying Target Machine and Compiler Version |
| =================================================== |
| |
| The usual way to run GCC is to run the executable called `gcc', or |
| `MACHINE-gcc' when cross-compiling, or `MACHINE-gcc-VERSION' to run a |
| version other than the one that was installed last. |
| |
| |
| File: gcc.info, Node: Submodel Options, Next: Code Gen Options, Prev: Target Options, Up: Invoking GCC |
| |
| 3.17 Hardware Models and Configurations |
| ======================================= |
| |
| Each target machine types can have its own special options, starting |
| with `-m', to choose among various hardware models or |
| configurations--for example, 68010 vs 68020, floating coprocessor or |
| none. A single installed version of the compiler can compile for any |
| model or configuration, according to the options specified. |
| |
| Some configurations of the compiler also support additional special |
| options, usually for compatibility with other compilers on the same |
| platform. |
| |
| * Menu: |
| |
| * 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:: |
| * IA-64/VMS Options:: |
| * LM32 Options:: |
| * M32C Options:: |
| * M32R/D Options:: |
| * M680x0 Options:: |
| * M68hc1x Options:: |
| * MCore Options:: |
| * MeP Options:: |
| * MicroBlaze Options:: |
| * MIPS Options:: |
| * MMIX Options:: |
| * MN10300 Options:: |
| * PDP-11 Options:: |
| * picoChip Options:: |
| * PowerPC Options:: |
| * RS/6000 and PowerPC Options:: |
| * RX Options:: |
| * S/390 and zSeries Options:: |
| * Score Options:: |
| * SH Options:: |
| * Solaris 2 Options:: |
| * SPARC Options:: |
| * SPU Options:: |
| * System V Options:: |
| * V850 Options:: |
| * VAX Options:: |
| * VxWorks Options:: |
| * x86-64 Options:: |
| * Xstormy16 Options:: |
| * Xtensa Options:: |
| * zSeries Options:: |
| |
| |
| 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::. |
| |
| |
| |
| 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. |
| |
| 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', |
| `arm1156t2f-s', `arm1176jz-s', `arm1176jzf-s', `cortex-a5', |
| `cortex-a8', `cortex-a9', `cortex-a15', `cortex-r4', `cortex-r4f', |
| `cortex-m4', `cortex-m3', `cortex-m1', `cortex-m0', `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-fp16', |
| `vfpv3-d16', `vfpv3-d16-fp16', `vfpv3xd', `vfpv3xd-fp16', `neon', |
| `neon-fp16', `vfpv4', `vfpv4-d16', `fpv4-sp-d16' and `neon-vfpv4'. |
| `-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. |
| |
| If the selected floating-point hardware includes the NEON extension |
| (e.g. `-mfpu'=`neon'), note that floating-point operations will |
| not be used by GCC's auto-vectorization pass unless |
| `-funsafe-math-optimizations' is also specified. This is because |
| NEON hardware does not fully implement the IEEE 754 standard for |
| floating-point arithmetic (in particular denormal values are |
| treated as zero), so the use of NEON instructions may lead to a |
| loss of precision. |
| |
| `-mfp16-format=NAME' |
| Specify the format of the `__fp16' half-precision floating-point |
| type. Permissible names are `none', `ieee', and `alternative'; |
| the default is `none', in which case the `__fp16' type is not |
| defined. *Note Half-Precision::, for more information. |
| |
| `-mstructure-size-boundary=N' |
| The 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. |
| This option is not passed to the assembler. If you want to force |
| assembler files to be interpreted as Thumb code, either add a |
| `.thumb' directive to the source or pass the `-mthumb' option |
| directly to the assembler by prefixing it with `-Wa'. |
| |
| `-mtpcs-frame' |
| Generate a stack frame that is compliant with the Thumb Procedure |
| Call Standard for all non-leaf functions. (A leaf function is one |
| that does not call any other functions.) The default is |
| `-mno-tpcs-frame'. |
| |
| `-mtpcs-leaf-frame' |
| Generate a stack frame that is compliant with the Thumb Procedure |
| Call Standard for all leaf functions. (A leaf function is one |
| that does not call any other functions.) The default is |
| `-mno-apcs-leaf-frame'. |
| |
| `-mcallee-super-interworking' |
| Gives all externally visible functions in the file being compiled |
| an ARM instruction set header which switches to Thumb mode before |
| executing the rest of the function. This allows these functions |
| to be called from non-interworking code. This option is not valid |
| in AAPCS configurations because interworking is enabled by default. |
| |
| `-mcaller-super-interworking' |
| Allows calls via function pointers (including virtual functions) to |
| execute correctly regardless of whether the target code has been |
| compiled for interworking or not. There is a small overhead in |
| the cost of executing a function pointer if this option is |
| enabled. This option is not valid in AAPCS configurations because |
| interworking is enabled by default. |
| |
| `-mtp=NAME' |
| Specify the access model for the thread local storage pointer. |
| The valid models are `soft', which generates calls to |
| `__aeabi_read_tp', `cp15', which fetches the thread pointer from |
| `cp15' directly (supported in the arm6k architecture), and `auto', |
| which uses the best available method for the selected processor. |
| The default setting is `auto'. |
| |
| `-mword-relocations' |
| Only generate absolute relocations on word sized values (i.e. |
| R_ARM_ABS32). This is enabled by default on targets (uClinux, |
| SymbianOS) where the runtime loader imposes this restriction, and |
| when `-fpic' or `-fPIC' is specified. |
| |
| `-mfix-cortex-m3-ldrd' |
| Some Cortex-M3 cores can cause data corruption when `ldrd' |
| instructions with overlapping destination and base registers are |
| used. This option avoids generating these instructions. This |
| option is enabled by default when `-mcpu=cortex-m3' is specified. |
| |
| |
| |
| 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). |
| |
| `-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. |
| |
| `-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, a 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. |
| |
| 3.17.3.1 `EIND' and Devices with more than 128k Bytes of Flash |
| .............................................................. |
| |
| Pointers in the implementation are 16 bits wide. The address of a |
| function or label is represented as word address so that indirect jumps |
| and calls can address any code address in the range of 64k words. |
| |
| In order to faciliate indirect jump on devices with more than 128k |
| bytes of program memory space, there is a special function register |
| called `EIND' that serves as most significant part of the target address |
| when `EICALL' or `EIJMP' instructions are used. |
| |
| Indirect jumps and calls on these devices are handled as follows and |
| are subject to some limitations: |
| |
| * The compiler never sets `EIND'. |
| |
| * The startup code from libgcc never sets `EIND'. Notice that |
| startup code is a blend of code from libgcc and avr-libc. For the |
| impact of avr-libc on `EIND', see the |
| avr-libc user manual (http://nongnu.org/avr-libc/user-manual). |
| |
| * The compiler uses `EIND' implicitely in `EICALL'/`EIJMP' |
| instructions or might read `EIND' directly. |
| |
| * The compiler assumes that `EIND' never changes during the startup |
| code or run of the application. In particular, `EIND' is not |
| saved/restored in function or interrupt service routine |
| prologue/epilogue. |
| |
| * It is legitimate for user-specific startup code to set up `EIND' |
| early, for example by means of initialization code located in |
| section `.init3', and thus prior to general startup code that |
| initializes RAM and calls constructors. |
| |
| * For indirect calls to functions and computed goto, the linker will |
| generate _stubs_. Stubs are jump pads sometimes also called |
| _trampolines_. Thus, the indirect call/jump will jump to such a |
| stub. The stub contains a direct jump to the desired address. |
| |
| * Stubs will be generated automatically by the linker if the |
| following two conditions are met: |
| - The address of a label is taken by means of the `gs' modifier |
| (short for _generate stubs_) like so: |
| LDI r24, lo8(gs(FUNC)) |
| LDI r25, hi8(gs(FUNC)) |
| |
| - The final location of that label is in a code segment |
| _outside_ the segment where the stubs are located. |
| |
| * The compiler will emit such `gs' modifiers for code labels in the |
| following situations: |
| - Taking address of a function or code label. |
| |
| - Computed goto. |
| |
| - If prologue-save function is used, see `-mcall-prologues' |
| command line option. |
| |
| - Switch/case dispatch tables. If you do not want such dispatch |
| tables you can specify the `-fno-jump-tables' command line |
| option. |
| |
| - C and C++ constructors/destructors called during |
| startup/shutdown. |
| |
| - If the tools hit a `gs()' modifier explained above. |
| |
| * The default linker script is arranged for code with `EIND = 0'. |
| If code is supposed to work for a setup with `EIND != 0', a custom |
| linker script has to be used in order to place the sections whose |
| name start with `.trampolines' into the segment where `EIND' |
| points to. |
| |
| * Jumping to non-symbolic addresses like so is _not_ supported: |
| |
| int main (void) |
| { |
| /* Call function at word address 0x2 */ |
| return ((int(*)(void)) 0x2)(); |
| } |
| |
| Instead, a stub has to be set up: |
| |
| int main (void) |
| { |
| extern int func_4 (void); |
| |
| /* Call function at byte address 0x4 */ |
| return func_4(); |
| } |
| |
| and the application be linked with `-Wl,--defsym,func_4=0x4'. |
| Alternatively, `func_4' can be defined in the linker script. |
| |
| |
| 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', `bf542m', `bf544m', `bf547m', |
| `bf548m', `bf549m', `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. |
| |
| |
| 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. |
| |
| |
| 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. |
| |
| |
| 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 a `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. |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| `-mdebug-main=PREFIX' |
| Flag the first routine whose name starts with PREFIX as the main |
| routine for the debugger. |
| |
| `-mmalloc64' |
| Default to 64bit memory allocation routines. |
| |
| |
| 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. |
| |
| |
| |
| 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'. |
| |
| |
| |
| 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. This is the default except on |
| `*-*-linux-*uclibc*' and `*-*-linux-*android*' targets. |
| |
| `-muclibc' |
| Use uClibc C library. This is the default on `*-*-linux-*uclibc*' |
| targets. |
| |
| `-mbionic' |
| Use Bionic C library. This is the default on |
| `*-*-linux-*android*' targets. |
| |
| `-mandroid' |
| Compile code compatible with Android platform. This is the |
| default on `*-*-linux-*android*' targets. |
| |
| When compiling, this option enables `-mbionic', `-fPIC', |
| `-fno-exceptions' and `-fno-rtti' by default. When linking, this |
| option makes the GCC driver pass Android-specific options to the |
| linker. Finally, this option causes the preprocessor macro |
| `__ANDROID__' to be defined. |
| |
| `-tno-android-cc' |
| Disable compilation effects of `-mandroid', i.e., do not enable |
| `-mbionic', `-fPIC', `-fno-exceptions' and `-fno-rtti' by default. |
| |
| `-tno-android-ld' |
| Disable linking effects of `-mandroid', i.e., pass standard Linux |
| linking options to the linker. |
| |
| |
| |
| File: gcc.info, Node: H8/300 Options, Next: HPPA Options, Prev: GNU/Linux Options, Up: Submodel Options |
| |
| 3.17.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. |
| |
| |
| 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. |
| |
| |
| 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. |
| |
| _corei7_ |
| Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, |
| SSE3, SSSE3, SSE4.1 and SSE4.2 instruction set support. |
| |
| _corei7-avx_ |
| Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, |
| SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES and PCLMUL instruction |
| set support. |
| |
| _core-avx-i_ |
| Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, |
| SSSE3, SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and |
| F16C instruction set support. |
| |
| _atom_ |
| Intel Atom 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. |
| |
| `-mvect8-ret-in-mem' |
| Return 8-byte vectors in memory instead of MMX registers. This is |
| the default on Solaris 8 and 9 and VxWorks to match the ABI of the |
| Sun Studio compilers until version 12. Later compiler versions |
| (starting with Studio 12 Update 1) follow the ABI used by other |
| x86 targets, which is the default on Solaris 10 and later. _Only_ |
| use this option if you need to remain compatible with existing |
| code produced by those previous compiler versions or older |
| versions of GCC. |
| |
| `-mpc32' |
| `-mpc64' |
| `-mpc80' |
| Set 80387 floating-point precision to 32, 64 or 80 bits. When |
| `-mpc32' is specified, the significands of results of |
| floating-point operations are rounded to 24 bits (single |
| precision); `-mpc64' rounds the significands of results of |
| floating-point operations to 53 bits (double precision) and |
| `-mpc80' rounds the significands of results of floating-point |
| operations to 64 bits (extended double precision), which is the |
| default. When this option is used, floating-point operations in |
| higher precisions are not available to the programmer without |
| setting the FPU control word explicitly. |
| |
| Setting the rounding of floating-point operations to less than the |
| default 80 bits can speed some programs by 2% or more. Note that |
| some mathematical libraries assume that extended precision (80 |
| bit) floating-point operations are enabled by default; routines in |
| such libraries could suffer significant loss of accuracy, |
| typically through so-called "catastrophic cancellation", when this |
| option is used to set the precision to less than extended |
| precision. |
| |
| `-mstackrealign' |
| Realign the stack at entry. On the Intel x86, the `-mstackrealign' |
| option 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' |
| `-mfsgsbase' |
| `-mno-fsgsbase' |
| `-mrdrnd' |
| `-mno-rdrnd' |
| `-mf16c' |
| `-mno-f16c' |
| `-msse4a' |
| `-mno-sse4a' |
| `-mfma4' |
| `-mno-fma4' |
| `-mxop' |
| `-mno-xop' |
| `-mlwp' |
| `-mno-lwp' |
| `-m3dnow' |
| `-mno-3dnow' |
| `-mpopcnt' |
| `-mno-popcnt' |
| `-mabm' |
| `-mno-abm' |
| `-mbmi' |
| `-mno-bmi' |
| `-mtbm' |
| `-mno-tbm' |
| These switches enable or disable the use of instructions in the |
| MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AES, PCLMUL, FSGSBASE, |
| RDRND, F16C, SSE4A, FMA4, XOP, LWP, ABM, BMI, 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. |
| |
| `-mfused-madd' |
| `-mno-fused-madd' |
| Do (don't) generate code that uses the fused multiply/add or |
| multiply/subtract instructions. The default is to use these |
| instructions. |
| |
| `-mcld' |
| This option instructs GCC to emit a `cld' instruction in the |
| prologue of functions that use string instructions. String |
| instructions depend on the DF flag to select between autoincrement |
| or autodecrement mode. While the ABI specifies the DF flag to be |
| cleared on function entry, some operating systems violate this |
| specification by not clearing the DF flag in their exception |
| dispatchers. The exception handler can be invoked with the DF flag |
| set which leads to wrong direction mode, when string instructions |
| are used. This option can be enabled by default on 32-bit x86 |
| targets by configuring GCC with the `--enable-cld' configure |
| option. Generation of `cld' instructions can be suppressed with |
| the `-mno-cld' compiler option in this case. |
| |
| `-mvzeroupper' |
| This option instructs GCC to emit a `vzeroupper' instruction |
| before a transfer of control flow out of the function to minimize |
| AVX to SSE transition penalty as well as remove unnecessary |
| zeroupper intrinsics. |
| |
| `-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. |
| |
| `-mmovbe' |
| This option will enable GCC to use movbe instruction to implement |
| `__builtin_bswap32' and `__builtin_bswap64'. |
| |
| `-mcrc32' |
| This option will enable built-in functions, |
| `__builtin_ia32_crc32qi', `__builtin_ia32_crc32hi'. |
| `__builtin_ia32_crc32si' and `__builtin_ia32_crc32di' to generate |
| the crc32 machine instruction. |
| |
| `-mrecip' |
| This option 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). |
| |
| Note that GCC implements 1.0f/sqrtf(x) in terms of RSQRTSS (or |
| RSQRTPS) already with `-ffast-math' (or the above option |
| combination), and doesn't need `-mrecip'. |
| |
| `-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. |
| |
| `-mabi=NAME' |
| Generate code for the specified calling convention. Permissible |
| values are: `sysv' for the ABI used on GNU/Linux and other systems |
| and `ms' for the Microsoft ABI. The default is to use the |
| Microsoft ABI when targeting Windows. On all other systems, the |
| default is the SYSV ABI. You can control this behavior for a |
| specific function by using the function attribute |
| `ms_abi'/`sysv_abi'. *Note Function Attributes::. |
| |
| `-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. |
| |
| `-msse2avx' |
| `-mno-sse2avx' |
| Specify that the assembler should encode SSE instructions with VEX |
| prefix. The option `-mavx' turns this on by default. |
| |
| `-mfentry' |
| `-mno-fentry' |
| If profiling is active `-pg' put the profiling counter call before |
| prologue. Note: On x86 architectures the attribute |
| `ms_hook_prologue' isn't possible at the moment for `-mfentry' and |
| `-pg'. |
| |
| `-m8bit-idiv' |
| `-mno-8bit-idiv' |
| On some processors, like Intel Atom, 8bit unsigned integer divide |
| is much faster than 32bit/64bit integer divide. This option will |
| generate a runt-time check. If both dividend and divisor are |
| within range of 0 to 255, 8bit unsigned integer divide will be |
| used instead of 32bit/64bit integer divide. |
| |
| `-mavx256-split-unaligned-load' |
| |
| `-mavx256-split-unaligned-store' |
| Split 32-byte AVX unaligned load and store. |
| |
| |
| 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. |
| |
| |
| 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.16 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 behavior |
| for Cygwin and MinGW targets. |
| |
| `-mdll' |
| This option is available for Cygwin and MinGW targets. It |
| specifies that a DLL - a dynamic link library - is to be |
| generated, enabling the selection of the required runtime startup |
| object and entry point. |
| |
| `-mnop-fun-dllimport' |
| This option is available for Cygwin and MinGW targets. It |
| specifies that the dllimport attribute should be ignored. |
| |
| `-mthread' |
| This option is available for MinGW targets. It specifies that |
| MinGW-specific thread support is to be used. |
| |
| `-municode' |
| This option is available for mingw-w64 targets. It specifies that |
| the UNICODE macro is getting pre-defined and that the unicode |
| capable runtime startup code is chosen. |
| |
| `-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. |
| |
| `-fno-set-stack-executable' |
| This option is available for MinGW targets. It specifies that the |
| executable flag for stack used by nested functions isn't set. This |
| is necessary for binaries running in kernel mode of Windows, as |
| there the user32 API, which is used to set executable privileges, |
| isn't available. |
| |
| `-mpe-aligned-commons' |
| This option is available for Cygwin and MinGW targets. It |
| specifies that the GNU extension to the PE file format that |
| permits the correct alignment of COMMON variables should be used |
| when generating code. It will be enabled by default if GCC |
| detects that the target assembler found during configuration |
| supports the feature. |
| |
| See also under *note i386 and x86-64 Options:: for standard options. |
| |
| |
| File: gcc.info, Node: IA-64 Options, Next: IA-64/VMS Options, Prev: i386 and x86-64 Windows Options, Up: Submodel Options |
| |
| 3.17.17 IA-64 Options |
| --------------------- |
| |
| These are the `-m' options defined for the Intel IA-64 architecture. |
| |
| `-mbig-endian' |
| Generate code for a big endian target. This is the default for |
| HP-UX. |
| |
| `-mlittle-endian' |
| Generate code for a little endian target. This is the default for |
| AIX5 and GNU/Linux. |
| |
| `-mgnu-as' |
| `-mno-gnu-as' |
| Generate (or don't) code for the GNU assembler. This is the |
| default. |
| |
| `-mgnu-ld' |
| `-mno-gnu-ld' |
| Generate (or don't) code for the GNU linker. This is the default. |
| |
| `-mno-pic' |
| Generate code that does not use a global pointer register. The |
| result is not position independent code, and violates the IA-64 |
| ABI. |
| |
| `-mvolatile-asm-stop' |
| `-mno-volatile-asm-stop' |
| Generate (or don't) a stop bit immediately before and after |
| volatile asm statements. |
| |
| `-mregister-names' |
| `-mno-register-names' |
| Generate (or don't) `in', `loc', and `out' register names for the |
| stacked registers. This may make assembler output more readable. |
| |
| `-mno-sdata' |
| `-msdata' |
| Disable (or enable) optimizations that use the small data section. |
| This may be useful for working around optimizer bugs. |
| |
| `-mconstant-gp' |
| Generate code that uses a single constant global pointer value. |
| This is useful when compiling kernel code. |
| |
| `-mauto-pic' |
| Generate code that is self-relocatable. This implies |
| `-mconstant-gp'. This is useful when compiling firmware code. |
| |
| `-minline-float-divide-min-latency' |
| Generate code for inline divides of floating point values using |
| the minimum latency algorithm. |
| |
| `-minline-float-divide-max-throughput' |
| Generate code for inline divides of floating point values using |
| the maximum throughput algorithm. |
| |
| `-mno-inline-float-divide' |
| Do not generate inline code for divides of floating point values. |
| |
| `-minline-int-divide-min-latency' |
| Generate code for inline divides of integer values using the |
| minimum latency algorithm. |
| |
| `-minline-int-divide-max-throughput' |
| Generate code for inline divides of integer values using the |
| maximum throughput algorithm. |
| |
| `-mno-inline-int-divide' |
| Do not generate inline code for divides of integer values. |
| |
| `-minline-sqrt-min-latency' |
| Generate code for inline square roots using the minimum latency |
| algorithm. |
| |
| `-minline-sqrt-max-throughput' |
| Generate code for inline square roots using the maximum throughput |
| algorithm. |
| |
| `-mno-inline-sqrt' |
| Do not generate inline code for sqrt. |
| |
| `-mfused-madd' |
| `-mno-fused-madd' |
| Do (don't) generate code that uses the fused multiply/add or |
| multiply/subtract instructions. The default is to use these |
| instructions. |
| |
| `-mno-dwarf2-asm' |
| `-mdwarf2-asm' |
| Don't (or do) generate assembler code for the 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. |
| |
| `-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'. |
| |
| `-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'. |
| |
| `-msched-spec-ldc' |
| Use a simple data speculation check. This option is on by default. |
| |
| `-msched-control-spec-ldc' |
| Use a simple check for control speculation. This option is on by |
| default. |
| |
| `-msched-stop-bits-after-every-cycle' |
| Place a stop bit after every cycle when scheduling. This option |
| is on by default. |
| |
| `-msched-fp-mem-deps-zero-cost' |
| Assume that floating-point stores and loads are not likely to |
| cause a conflict when placed into the same instruction group. |
| This option is disabled by default. |
| |
| `-msel-sched-dont-check-control-spec' |
| Generate checks for control speculation in selective scheduling. |
| This flag is disabled by default. |
| |
| `-msched-max-memory-insns=MAX-INSNS' |
| Limit on the number of memory insns per instruction group, giving |
| lower priority to subsequent memory insns attempting to schedule |
| in the same instruction group. Frequently useful to prevent cache |
| bank conflicts. The default value is 1. |
| |
| `-msched-max-memory-insns-hard-limit' |
| Disallow more than `msched-max-memory-insns' in instruction group. |
| Otherwise, limit is `soft' meaning that we would prefer non-memory |
| operations when limit is reached but may still schedule memory |
| operations. |
| |
| |
| |
| File: gcc.info, Node: IA-64/VMS Options, Next: LM32 Options, Prev: IA-64 Options, Up: Submodel Options |
| |
| 3.17.18 IA-64/VMS Options |
| ------------------------- |
| |
| These `-m' options are defined for the IA-64/VMS implementations: |
| |
| `-mvms-return-codes' |
| Return VMS condition codes from main. The default is to return |
| POSIX style condition (e.g. error) codes. |
| |
| `-mdebug-main=PREFIX' |
| Flag the first routine whose name starts with PREFIX as the main |
| routine for the debugger. |
| |
| `-mmalloc64' |
| Default to 64bit memory allocation routines. |
| |
| |
| File: gcc.info, Node: LM32 Options, Next: M32C Options, Prev: IA-64/VMS Options, Up: Submodel Options |
| |
| 3.17.19 LM32 Options |
| -------------------- |
| |
| These `-m' options are defined for the Lattice Mico32 architecture: |
| |
| `-mbarrel-shift-enabled' |
| Enable barrel-shift instructions. |
| |
| `-mdivide-enabled' |
| Enable divide and modulus instructions. |
| |
| `-mmultiply-enabled' |
| Enable multiply instructions. |
| |
| `-msign-extend-enabled' |
| Enable sign extend instructions. |
| |
| `-muser-enabled' |
| Enable user-defined instructions. |
| |
| |
| |
| File: gcc.info, Node: M32C Options, Next: M32R/D Options, Prev: LM32 Options, Up: Submodel Options |
| |
| 3.17.20 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. |
| |
| |
| |
| File: gcc.info, Node: M32R/D Options, Next: M680x0 Options, Prev: M32C Options, Up: Submodel Options |
| |
| 3.17.21 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. |
| |
| |
| |
| File: gcc.info, Node: M680x0 Options, Next: M68hc1x Options, Prev: M32R/D Options, Up: Submodel Options |
| |
| 3.17.22 M680x0 Options |
| ---------------------- |
| |
| These are the `-m' options defined for M680x0 and ColdFire processors. |
| The default settings depend on which architecture was selected when the |
| compiler was configured; the defaults for the most common choices are |
| given below. |
| |
| `-march=ARCH' |
| Generate code for a specific M680x0 or ColdFire instruction set |
| architecture. Permissible values of ARCH for M680x0 architectures |
| are: `68000', `68010', `68020', `68030', `68040', `68060' and |
| `cpu32'. ColdFire architectures are selected according to |
| Freescale's ISA classification and the permissible values are: |
| `isaa', `isaaplus', `isab' and `isac'. |
| |
| gcc defines a macro `__mcfARCH__' whenever it is generating code |
| for a ColdFire target. The ARCH in this macro is one of the |
| `-march' arguments given above. |
| |
| When used together, `-march' and `-mtune' select code that runs on |
| a family of similar processors but that is optimized for a |
| particular microarchitecture. |
| |
| `-mcpu=CPU' |
| Generate code for a specific M680x0 or ColdFire processor. The |
| M680x0 CPUs are: `68000', `68010', `68020', `68030', `68040', |
| `68060', `68302', `68332' and `cpu32'. The ColdFire CPUs are |
| given by the table below, which also classifies the CPUs into |
| families: |
| |
| *Family* *`-mcpu' arguments* |
| `51' `51' `51ac' `51cn' `51em' `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' |
| `52259' `52252' `52254' `52255' `52256' `52258' `52259' |
| `5235' `5232' `5233' `5234' `5235' `523x' |
| `5249' `5249' |
| `5250' `5250' |
| `5271' `5270' `5271' |
| `5272' `5272' |
| `5275' `5274' `5275' |
| `5282' `5280' `5281' `5282' `528x' |
| `53017' `53011' `53012' `53013' `53014' `53015' `53016' |
| `53017' |
| `5307' `5307' |
| `5329' `5327' `5328' `5329' `532x' |
| `5373' `5372' `5373' `537x' |
| `5407' `5407' |
| `5475' `5470' `5471' `5472' `5473' `5474' `5475' `547x' |
| `5480' `5481' `5482' `5483' `5484' `5485' |
| |
| `-mcpu=CPU' overrides `-march=ARCH' if ARCH is compatible with |
| CPU. Other combinations of `-mcpu' and `-march' are rejected. |
| |
| gcc defines the macro `__mcf_cpu_CPU' when ColdFire target CPU is |
| selected. It also defines `__mcf_family_FAMILY', where the value |
| of FAMILY is given by the table above. |
| |
| `-mtune=TUNE' |
| Tune the code for a particular microarchitecture, within the |
| constraints set by `-march' and `-mcpu'. The M680x0 |
| microarchitectures are: `68000', `68010', `68020', `68030', |
| `68040', `68060' and `cpu32'. The ColdFire microarchitectures |
| are: `cfv1', `cfv2', `cfv3', `cfv4' and `cfv4e'. |
| |
| You can also use `-mtune=68020-40' for code that needs to run |
| relatively well on 68020, 68030 and 68040 targets. |
| `-mtune=68020-60' is similar but includes 68060 targets as well. |
| These two options select the same tuning decisions as `-m68020-40' |
| and `-m68020-60' respectively. |
| |
| gcc defines the macros `__mcARCH' and `__mcARCH__' when tuning for |
| 680x0 architecture ARCH. It also defines `mcARCH' unless either |
| `-ansi' or a non-GNU `-std' option is used. If gcc is tuning for |
| a range of architectures, as selected by `-mtune=68020-40' or |
| `-mtune=68020-60', it defines the macros for every architecture in |
| the range. |
| |
| gcc also defines the macro `__mUARCH__' when tuning for ColdFire |
| microarchitecture UARCH, where UARCH is one of the arguments given |
| above. |
| |
| `-m68000' |
| `-mc68000' |
| Generate output for a 68000. This is the default when the |
| compiler is configured for 68000-based systems. It is equivalent |
| to `-march=68000'. |
| |
| Use this option for microcontrollers with a 68000 or EC000 core, |
| including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356. |
| |
| `-m68010' |
| Generate output for a 68010. This is the default when the |
| compiler is configured for 68010-based systems. It is equivalent |
| to `-march=68010'. |
| |
| `-m68020' |
| `-mc68020' |
| Generate output for a 68020. This is the default when the |
| compiler is configured for 68020-based systems. It is equivalent |
| to `-march=68020'. |
| |
| `-m68030' |
| Generate output for a 68030. This is the default when the |
| compiler is configured for 68030-based systems. It is equivalent |
| to `-march=68030'. |
| |
| `-m68040' |
| Generate output for a 68040. This is the default when the |
| compiler is configured for 68040-based systems. It is equivalent |
| to `-march=68040'. |
| |
| This option inhibits the use of 68881/68882 instructions that have |
| to be emulated by software on the 68040. Use this option if your |
| 68040 does not have code to emulate those instructions. |
| |
| `-m68060' |
| Generate output for a 68060. This is the default when the |
| compiler is configured for 68060-based systems. It is equivalent |
| to `-march=68060'. |
| |
| This option inhibits the use of 68020 and 68881/68882 instructions |
| that have to be emulated by software on the 68060. Use this |
| option if your 68060 does not have code to emulate those |
| instructions. |
| |
| `-mcpu32' |
| Generate output for a CPU32. This is the default when the |
| compiler is configured for CPU32-based systems. It is equivalent |
| to `-march=cpu32'. |
| |
| Use this option for microcontrollers with a CPU32 or CPU32+ core, |
| including the 68330, 68331, 68332, 68333, 68334, 68336, 68340, |
| 68341, 68349 and 68360. |
| |
| `-m5200' |
| Generate output for a 520X ColdFire CPU. This is the default when |
| the compiler is configured for 520X-based systems. It is |
| equivalent to `-mcpu=5206', and is now deprecated in favor of that |
| option. |
| |
| Use this option for microcontroller with a 5200 core, including |
| the MCF5202, MCF5203, MCF5204 and MCF5206. |
| |
| `-m5206e' |
| Generate output for a 5206e ColdFire CPU. The option is now |
| deprecated in favor of the equivalent `-mcpu=5206e'. |
| |
| `-m528x' |
| Generate output for a member of the ColdFire 528X family. The |
| option is now deprecated in favor of the equivalent `-mcpu=528x'. |
| |
| `-m5307' |
| Generate output for a ColdFire 5307 CPU. The option is now |
| deprecated in favor of the equivalent `-mcpu=5307'. |
| |
| `-m5407' |
| Generate output for a ColdFire 5407 CPU. The option is now |
| deprecated in favor of the equivalent `-mcpu=5407'. |
| |
| `-mcfv4e' |
| Generate output for a ColdFire V4e family CPU (e.g. 547x/548x). |
| This includes use of hardware floating point instructions. The |
| option is equivalent to `-mcpu=547x', and is now deprecated in |
| favor of that option. |
| |
| `-m68020-40' |
| Generate output for a 68040, without using any of the new |
| instructions. This results in code 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. |
| |
| |
| |
| File: gcc.info, Node: M68hc1x Options, Next: MCore Options, Prev: M680x0 Options, Up: Submodel Options |
| |
| 3.17.23 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' |
| `-mnominmax' |
| 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. |
| |
| |
| |
| File: gcc.info, Node: MCore Options, Next: MeP Options, Prev: M68hc1x Options, Up: Submodel Options |
| |
| 3.17.24 MCore Options |
| --------------------- |
| |
| These are the `-m' options defined for the Motorola M*Core processors. |
| |
| `-mhardlit' |
| `-mno-hardlit' |
| Inline constants into the code stream if it can be done in two |
| instructions or less. |
| |
| `-mdiv' |
| `-mno-div' |
| Use the divide instruction. (Enabled by default). |
| |
| `-mrelax-immediate' |
| `-mno-relax-immediate' |
| Allow arbitrary sized immediates in bit operations. |
| |
| `-mwide-bitfields' |
| `-mno-wide-bitfields' |
| Always treat bit-fields as int-sized. |
| |
| `-m4byte-functions' |
| `-mno-4byte-functions' |
| Force all functions to be aligned to a 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. |
| |
| |
| |
| File: gcc.info, Node: MeP Options, Next: MicroBlaze Options, Prev: MCore Options, Up: Submodel Options |
| |
| 3.17.25 MeP Options |
| ------------------- |
| |
| `-mabsdiff' |
| Enables the `abs' instruction, which is the absolute difference |
| between two registers. |
| |
| `-mall-opts' |
| Enables all the optional instructions - average, multiply, divide, |
| bit operations, leading zero, absolute difference, min/max, clip, |
| and saturation. |
| |
| `-maverage' |
| Enables the `ave' instruction, which computes the average of two |
| registers. |
| |
| `-mbased=N' |
| Variables of size N bytes or smaller will be placed in the |
| `.based' section by default. Based variables use the `$tp' |
| register as a base register, and there is a 128 byte limit to the |
| `.based' section. |
| |
| `-mbitops' |
| Enables the bit operation instructions - bit test (`btstm'), set |
| (`bsetm'), clear (`bclrm'), invert (`bnotm'), and test-and-set |
| (`tas'). |
| |
| `-mc=NAME' |
| Selects which section constant data will be placed in. NAME may |
| be `tiny', `near', or `far'. |
| |
| `-mclip' |
| Enables the `clip' instruction. Note that `-mclip' is not useful |
| unless you also provide `-mminmax'. |
| |
| `-mconfig=NAME' |
| Selects one of the build-in core configurations. Each MeP chip has |
| one or more modules in it; each module has a core CPU and a |
| variety of coprocessors, optional instructions, and peripherals. |
| The `MeP-Integrator' tool, not part of GCC, provides these |
| configurations through this option; using this option is the same |
| as using all the corresponding command line options. The default |
| configuration is `default'. |
| |
| `-mcop' |
| Enables the coprocessor instructions. By default, this is a 32-bit |
| coprocessor. Note that the coprocessor is normally enabled via the |
| `-mconfig=' option. |
| |
| `-mcop32' |
| Enables the 32-bit coprocessor's instructions. |
| |
| `-mcop64' |
| Enables the 64-bit coprocessor's instructions. |
| |
| `-mivc2' |
| Enables IVC2 scheduling. IVC2 is a 64-bit VLIW coprocessor. |
| |
| `-mdc' |
| Causes constant variables to be placed in the `.near' section. |
| |
| `-mdiv' |
| Enables the `div' and `divu' instructions. |
| |
| `-meb' |
| Generate big-endian code. |
| |
| `-mel' |
| Generate little-endian code. |
| |
| `-mio-volatile' |
| Tells the compiler that any variable marked with the `io' |
| attribute is to be considered volatile. |
| |
| `-ml' |
| Causes variables to be assigned to the `.far' section by default. |
| |
| `-mleadz' |
| Enables the `leadz' (leading zero) instruction. |
| |
| `-mm' |
| Causes variables to be assigned to the `.near' section by default. |
| |
| `-mminmax' |
| Enables the `min' and `max' instructions. |
| |
| `-mmult' |
| Enables the multiplication and multiply-accumulate instructions. |
| |
| `-mno-opts' |
| Disables all the optional instructions enabled by `-mall-opts'. |
| |
| `-mrepeat' |
| Enables the `repeat' and `erepeat' instructions, used for |
| low-overhead looping. |
| |
| `-ms' |
| Causes all variables to default to the `.tiny' section. Note that |
| there is a 65536 byte limit to this section. Accesses to these |
| variables use the `%gp' base register. |
| |
| `-msatur' |
| Enables the saturation instructions. Note that the compiler does |
| not currently generate these itself, but this option is included |
| for compatibility with other tools, like `as'. |
| |
| `-msdram' |
| Link the SDRAM-based runtime instead of the default ROM-based |
| runtime. |
| |
| `-msim' |
| Link the simulator runtime libraries. |
| |
| `-msimnovec' |
| Link the simulator runtime libraries, excluding built-in support |
| for reset and exception vectors and tables. |
| |
| `-mtf' |
| Causes all functions to default to the `.far' section. Without |
| this option, functions default to the `.near' section. |
| |
| `-mtiny=N' |
| Variables that are N bytes or smaller will be allocated to the |
| `.tiny' section. These variables use the `$gp' base register. |
| The default for this option is 4, but note that there's a 65536 |
| byte limit to the `.tiny' section. |
| |
| |
| |
| File: gcc.info, Node: MicroBlaze Options, Next: MIPS Options, Prev: MeP Options, Up: Submodel Options |
| |
| 3.17.26 MicroBlaze Options |
| -------------------------- |
| |
| `-msoft-float' |
| Use software emulation for floating point (default). |
| |
| `-mhard-float' |
| Use hardware floating point instructions. |
| |
| `-mmemcpy' |
| Do not optimize block moves, use `memcpy'. |
| |
| `-mno-clearbss' |
| This option is deprecated. Use `-fno-zero-initialized-in-bss' |
| instead. |
| |
| `-mcpu=CPU-TYPE' |
| Use features of and schedule code for given CPU. Supported values |
| are in the format `vX.YY.Z', where X is a major version, YY is the |
| minor version, and Z is compatibility code. Example values are |
| `v3.00.a', `v4.00.b', `v5.00.a', `v5.00.b', `v5.00.b', `v6.00.a'. |
| |
| `-mxl-soft-mul' |
| Use software multiply emulation (default). |
| |
| `-mxl-soft-div' |
| Use software emulation for divides (default). |
| |
| `-mxl-barrel-shift' |
| Use the hardware barrel shifter. |
| |
| `-mxl-pattern-compare' |
| Use pattern compare instructions. |
| |
| `-msmall-divides' |
| Use table lookup optimization for small signed integer divisions. |
| |
| `-mxl-stack-check' |
| This option is deprecated. Use -fstack-check instead. |
| |
| `-mxl-gp-opt' |
| Use GP relative sdata/sbss sections. |
| |
| `-mxl-multiply-high' |
| Use multiply high instructions for high part of 32x32 multiply. |
| |
| `-mxl-float-convert' |
| Use hardware floating point conversion instructions. |
| |
| `-mxl-float-sqrt' |
| Use hardware floating point square root instruction. |
| |
| `-mxl-mode-APP-MODEL' |
| Select application model APP-MODEL. Valid models are |
| `executable' |
| normal executable (default), uses startup code `crt0.o'. |
| |
| `xmdstub' |
| for use with Xilinx Microprocessor Debugger (XMD) based |
| software intrusive debug agent called xmdstub. This uses |
| startup file `crt1.o' and sets the start address of the |
| program to be 0x800. |
| |
| `bootstrap' |
| for applications that are loaded using a bootloader. This |
| model uses startup file `crt2.o' which does not contain a |
| processor reset vector handler. This is suitable for |
| transferring control on a processor reset to the bootloader |
| rather than the application. |
| |
| `novectors' |
| for applications that do not require any of the MicroBlaze |
| vectors. This option may be useful for applications running |
| within a monitoring application. This model uses `crt3.o' as |
| a startup file. |
| |
| Option `-xl-mode-APP-MODEL' is a deprecated alias for |
| `-mxl-mode-APP-MODEL'. |
| |
| |
| |
| File: gcc.info, Node: MIPS Options, Next: MMIX Options, Prev: MicroBlaze Options, Up: Submodel Options |
| |
| 3.17.27 MIPS Options |
| -------------------- |
| |
| `-EB' |
| Generate big-endian code. |
| |
| `-EL' |
| Generate little-endian code. This is the default for `mips*el-*-*' |
| configurations. |
| |
| `-march=ARCH' |
| Generate code that 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', `1004kc', `1004kf2_1', |
| `1004kf1_1', `loongson2e', `loongson2f', `loongson3a', `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'. |
| |
| `-msynci' |
| `-mno-synci' |
| Enable (disable) generation of `synci' instructions on |
| architectures that support it. The `synci' instructions (if |
| enabled) will be generated when `__builtin___clear_cache()' is |
| compiled. |
| |
| This option defaults to `-mno-synci', but the default can be |
| overridden by configuring with `--with-synci'. |
| |
| When compiling code for single processor systems, it is generally |
| safe to use `synci'. However, on many multi-core (SMP) systems, it |
| will not invalidate the instruction caches on all cores and may |
| lead to undefined behavior. |
| |
| `-mrelax-pic-calls' |
| `-mno-relax-pic-calls' |
| Try to turn PIC calls that are normally dispatched via register |
| `$25' into direct calls. This is only possible if the linker can |
| resolve the destination at link-time and if the destination is |
| within range for a direct call. |
| |
| `-mrelax-pic-calls' is the default if GCC was configured to use an |
| assembler and a linker that supports the `.reloc' assembly |
| directive and `-mexplicit-relocs' is in effect. With |
| `-mno-explicit-relocs', this optimization can be performed by the |
| assembler and the linker alone without help from the compiler. |
| |
| `-mmcount-ra-address' |
| `-mno-mcount-ra-address' |
| Emit (do not emit) code that allows `_mcount' to modify the |
| calling function's return address. When enabled, this option |
| extends the usual `_mcount' interface with a new RA-ADDRESS |
| parameter, which has type `intptr_t *' and is passed in register |
| `$12'. `_mcount' can then modify the return address by doing both |
| of the following: |
| * Returning the new address in register `$31'. |
| |
| * Storing the new address in `*RA-ADDRESS', if RA-ADDRESS is |
| nonnull. |
| |
| The default is `-mno-mcount-ra-address'. |
| |
| |
| |
| File: gcc.info, Node: MMIX Options, Next: MN10300 Options, Prev: MIPS Options, Up: Submodel Options |
| |
| 3.17.28 MMIX Options |
| -------------------- |
| |
| These options are defined for the MMIX: |
| |
| `-mlibfuncs' |
| `-mno-libfuncs' |
| Specify that intrinsic library functions are being compiled, |
| passing all values in registers, no matter the size. |
| |
| `-mepsilon' |
| `-mno-epsilon' |
| Generate floating-point comparison instructions that compare with |
| respect to the `rE' epsilon register. |
| |
| `-mabi=mmixware' |
| `-mabi=gnu' |
| Generate code that passes function parameters and return values |
| that (in the called function) are seen as registers `$0' and up, |
| as opposed to the GNU ABI which uses global registers `$231' and |
| up. |
| |
| `-mzero-extend' |
| `-mno-zero-extend' |
| When reading data from memory in sizes shorter than 64 bits, use |
| (do not use) zero-extending load instructions by default, rather |
| than sign-extending ones. |
| |
| `-mknuthdiv' |
| `-mno-knuthdiv' |
| Make the result of a division yielding a remainder have the same |
| sign as the divisor. With the default, `-mno-knuthdiv', the sign |
| of the remainder follows the sign of the dividend. Both methods |
| are arithmetically valid, the latter being almost exclusively used. |
| |
| `-mtoplevel-symbols' |
| `-mno-toplevel-symbols' |
| Prepend (do not prepend) a `:' to all global symbols, so the |
| assembly code can be used with the `PREFIX' assembly directive. |
| |
| `-melf' |
| Generate an executable in the ELF format, rather than the default |
| `mmo' format used by the `mmix' simulator. |
| |
| `-mbranch-predict' |
| `-mno-branch-predict' |
| Use (do not use) the probable-branch instructions, when static |
| branch prediction indicates a probable branch. |
| |
| `-mbase-addresses' |
| `-mno-base-addresses' |
| Generate (do not generate) code that uses _base addresses_. Using |
| a base address automatically generates a request (handled by the |
| assembler and the linker) for a constant to be set up in a global |
| register. The register is used for one or more base address |
| requests within the range 0 to 255 from the value held in the |
| register. The generally leads to short and fast code, but the |
| number of different data items that can be addressed is limited. |
| This means that a program that uses lots of static data may |
| require `-mno-base-addresses'. |
| |
| `-msingle-exit' |
| `-mno-single-exit' |
| Force (do not force) generated code to have a single exit point in |
| each function. |
| |
| |
| File: gcc.info, Node: MN10300 Options, Next: PDP-11 Options, Prev: MMIX Options, Up: Submodel Options |
| |
| 3.17.29 MN10300 Options |
| ----------------------- |
| |
| These `-m' options are defined for Matsushita MN10300 architectures: |
| |
| `-mmult-bug' |
| Generate code to avoid bugs in the multiply instructions for the |
| MN10300 processors. This is the default. |
| |
| `-mno-mult-bug' |
| Do not generate code to avoid bugs in the multiply instructions |
| for the MN10300 processors. |
| |
| `-mam33' |
| Generate code 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. |
| |
| `-mam33-2' |
| Generate code which uses features specific to the AM33/2.0 |
| processor. |
| |
| `-mam34' |
| Generate code which uses features specific to the AM34 processor. |
| |
| `-mtune=CPU-TYPE' |
| Use the timing characteristics of the indicated CPU type when |
| scheduling instructions. This does not change the targeted |
| processor type. The CPU type must be one of `mn10300', `am33', |
| `am33-2' or `am34'. |
| |
| `-mreturn-pointer-on-d0' |
| When generating a function 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. |
| |
| `-mliw' |
| Allow the compiler to generate _Long Instruction Word_ |
| instructions if the target is the `AM33' or later. This is the |
| default. This option defines the preprocessor macro `__LIW__'. |
| |
| `-mnoliw' |
| Do not allow the compiler to generate _Long Instruction Word_ |
| instructions. This option defines the preprocessor macro |
| `__NO_LIW__'. |
| |
| |
| |
| File: gcc.info, Node: PDP-11 Options, Next: picoChip Options, Prev: MN10300 Options, Up: Submodel Options |
| |
| 3.17.30 PDP-11 Options |
| ---------------------- |
| |
| These options are defined for the PDP-11: |
| |
| `-mfpu' |
| Use hardware FPP floating point. This is the default. (FIS |
| floating point on the PDP-11/40 is not supported.) |
| |
| `-msoft-float' |
| Do not use hardware floating point. |
| |
| `-mac0' |
| Return floating-point results in ac0 (fr0 in Unix assembler |
| syntax). |
| |
| `-mno-ac0' |
| Return floating-point results in memory. This is the default. |
| |
| `-m40' |
| Generate code for a PDP-11/40. |
| |
| `-m45' |
| Generate code for a PDP-11/45. This is the default. |
| |
| `-m10' |
| Generate code for a PDP-11/10. |
| |
| `-mbcopy-builtin' |
| Use inline `movmemhi' patterns for copying memory. This is the |
| default. |
| |
| `-mbcopy' |
| Do not use inline `movmemhi' patterns for copying memory. |
| |
| `-mint16' |
| `-mno-int32' |
| Use 16-bit `int'. This is the default. |
| |
| `-mint32' |
| `-mno-int16' |
| Use 32-bit `int'. |
| |
| `-mfloat64' |
| `-mno-float32' |
| Use 64-bit `float'. This is the default. |
| |
| `-mfloat32' |
| `-mno-float64' |
| Use 32-bit `float'. |
| |
| `-mabshi' |
| Use `abshi2' pattern. This is the default. |
| |
| `-mno-abshi' |
| Do not use `abshi2' pattern. |
| |
| `-mbranch-expensive' |
| Pretend that branches are expensive. This is for experimenting |
| with code generation only. |
| |
| `-mbranch-cheap' |
| Do not pretend that branches are expensive. This is the default. |
| |
| `-munix-asm' |
| Use Unix assembler syntax. This is the default when configured for |
| `pdp11-*-bsd'. |
| |
| `-mdec-asm' |
| Use DEC assembler syntax. This is the default when configured for |
| any PDP-11 target other than `pdp11-*-bsd'. |
| |
| |
| File: gcc.info, Node: picoChip Options, Next: PowerPC Options, Prev: PDP-11 Options, Up: Submodel Options |
| |
| 3.17.31 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. |
| |
| |
| |
| File: gcc.info, Node: PowerPC Options, Next: RS/6000 and PowerPC Options, Prev: picoChip Options, Up: Submodel Options |
| |
| 3.17.32 PowerPC Options |
| ----------------------- |
| |
| These are listed under *Note RS/6000 and PowerPC Options::. |
| |
| |
| File: gcc.info, Node: RS/6000 and PowerPC Options, Next: RX Options, Prev: PowerPC Options, Up: Submodel Options |
| |
| 3.17.33 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' |
| `-mpopcntd' |
| `-mno-popcntd' |
| `-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 `-mpopcntd' option |
| allows GCC to generate the popcount instruction implemented on the |
| POWER7 processor and other processors that support the PowerPC |
| V2.06 architecture. The `-mfprnd' option allows GCC to generate |
| the FP round to integer instructions implemented on the POWER5+ |
| processor and other processors that support the PowerPC V2.03 |
| architecture. The `-mcmpb' option allows GCC to generate the |
| compare bytes instruction implemented on the POWER6 processor and |
| other processors that support the PowerPC V2.05 architecture. The |
| `-mmfpgpr' option allows GCC to generate the FP move to/from |
| general purpose register instructions implemented on the POWER6X |
| processor and other processors that support the extended PowerPC |
| V2.05 architecture. The `-mhard-dfp' option allows GCC to |
| generate the decimal floating point instructions implemented on |
| some POWER processors. |
| |
| The `-mpowerpc64' option allows GCC to generate the additional |
| 64-bit instructions that are found in the full PowerPC64 |
| architecture and to treat GPRs as 64-bit, doubleword quantities. |
| GCC defaults to `-mno-powerpc64'. |
| |
| 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', `476', `476fp', `505', `601', |
| `602', `603', `603e', `604', `604e', `620', `630', `740', `7400', |
| `7450', `750', `801', `821', `823', `860', `970', `8540', `a2', |
| `e300c2', `e300c3', `e500mc', `e500mc64', `ec603e', `G3', `G4', |
| `G5', `titan', `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 -mpopcntd -mpower -mpower2 -mpowerpc64 |
| -mpowerpc-gpopt -mpowerpc-gfxopt -msingle-float -mdouble-float |
| -msimple-fpu -mstring -mmulhw -mdlmzb -mmfpgpr -mvsx |
| |
| 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'. |
| |
| `-mcmodel=small' |
| Generate PowerPC64 code for the small model: The TOC is limited to |
| 64k. |
| |
| `-mcmodel=medium' |
| Generate PowerPC64 code for the medium model: The TOC and other |
| static data may be up to a total of 4G in size. |
| |
| `-mcmodel=large' |
| Generate PowerPC64 code for the large model: The TOC may be up to |
| 4G in size. Other data and code is only limited by the 64-bit |
| address space. |
| |
| `-maltivec' |
| `-mno-altivec' |
| Generate code that uses (does not use) AltiVec instructions, and |
| also enable the use of built-in functions that allow more direct |
| access to the AltiVec instruction set. You may also need to set |
| `-mabi=altivec' to adjust the current ABI with AltiVec ABI |
| enhancements. |
| |
| `-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. |
| |
| `-mvsx' |
| `-mno-vsx' |
| Generate code that uses (does not use) vector/scalar (VSX) |
| instructions, and also enable the use of built-in functions that |
| allow more direct access to the VSX instruction set. |
| |
| `-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 point is used. The machine dependent |
| `-mfused-madd' option is now mapped to the machine independent |
| `-ffp-contract=fast' option, and `-mno-fused-madd' is mapped to |
| `-ffp-contract=off'. |
| |
| `-mmulhw' |
| `-mno-mulhw' |
| Generate code that uses (does not use) the half-word multiply and |
| multiply-accumulate instructions on the IBM 405, 440, 464 and 476 |
| processors. These instructions are generated by default when |
| targetting those processors. |
| |
| `-mdlmzb' |
| `-mno-dlmzb' |
| Generate code that uses (does not use) the string-search `dlmzb' |
| instruction on the IBM 405, 440, 464 and 476 processors. This |
| instruction is generated by default when 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' |
| Generate code that allows (does not allow) a static executable to |
| be relocated to a different address at runtime. A simple embedded |
| PowerPC system loader should relocate the entire contents of |
| `.got2' and 4-byte locations listed in the `.fixup' section, a |
| table of 32-bit addresses generated by this option. For this to |
| work, all objects linked together must be compiled with |
| `-mrelocatable' or `-mrelocatable-lib'. `-mrelocatable' code |
| aligns the stack to an 8 byte boundary. |
| |
| `-mrelocatable-lib' |
| `-mno-relocatable-lib' |
| Like `-mrelocatable', `-mrelocatable-lib' generates a `.fixup' |
| section to allow static executables to be relocated at runtime, |
| but `-mrelocatable-lib' does not use the smaller stack alignment |
| of `-mrelocatable'. Objects compiled with `-mrelocatable-lib' may |
| be linked with objects compiled with any combination of the |
| `-mrelocatable' options. |
| |
| `-mno-toc' |
| `-mtoc' |
| On System V.4 and embedded PowerPC systems do not (do) assume that |
| register 2 contains a pointer to a global area pointing to the |
| addresses used in the program. |
| |
| `-mlittle' |
| `-mlittle-endian' |
| On System V.4 and embedded PowerPC systems compile code for the |
| processor in little endian mode. The `-mlittle-endian' option is |
| the same as `-mlittle'. |
| |
| `-mbig' |
| `-mbig-endian' |
| On System V.4 and embedded PowerPC systems compile code for the |
| processor in big endian mode. The `-mbig-endian' option is the |
| same as `-mbig'. |
| |
| `-mdynamic-no-pic' |
| On Darwin and Mac OS X systems, compile code so that it is not |
| relocatable, but that its external references are relocatable. The |
| resulting code is suitable for applications, but not shared |
| libraries. |
| |
| `-msingle-pic-base' |
| Treat the register used for PIC addressing as read-only, rather |
| than loading it in the prologue for each function. The run-time |
| system is responsible for initializing this register with an |
| appropriate value before execution begins. |
| |
| `-mprioritize-restricted-insns=PRIORITY' |
| This option controls the priority that is assigned to |
| dispatch-slot restricted instructions during the second scheduling |
| pass. The argument PRIORITY takes the value 0/1/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' |
| `-mcall-eabi' |
| Specify both `-mcall-sysv' and `-meabi' options. |
| |
| `-mcall-sysv-noeabi' |
| Specify both `-mcall-sysv' and `-mno-eabi' options. |
| |
| `-mcall-aixdesc' |
| On System V.4 and embedded PowerPC systems compile code for the AIX |
| operating system. |
| |
| `-mcall-linux' |
| On System V.4 and embedded PowerPC systems compile code for the |
| Linux-based GNU system. |
| |
| `-mcall-gnu' |
| On System V.4 and embedded PowerPC systems compile code for the |
| Hurd-based GNU system. |
| |
| `-mcall-freebsd' |
| On System V.4 and embedded PowerPC systems compile code for the |
| FreeBSD operating system. |
| |
| `-mcall-netbsd' |
| On System V.4 and embedded PowerPC systems compile code for the |
| NetBSD operating system. |
| |
| `-mcall-openbsd' |
| On System V.4 and embedded PowerPC systems compile code for the |
| OpenBSD operating system. |
| |
| `-maix-struct-return' |
| Return all structures in memory (as specified by the AIX ABI). |
| |
| `-msvr4-struct-return' |
| Return structures smaller than 8 bytes in registers (as specified |
| by the SVR4 ABI). |
| |
| `-mabi=ABI-TYPE' |
| Extend the current ABI with a particular extension, or remove such |
| extension. Valid values are ALTIVEC, NO-ALTIVEC, SPE, NO-SPE, |
| IBMLONGDOUBLE, IEEELONGDOUBLE. |
| |
| `-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. |
| |
| `-mblock-move-inline-limit=NUM' |
| Inline all block moves (such as calls to `memcpy' or structure |
| copies) less than or equal to NUM bytes. The minimum value for |
| NUM is 32 bytes on 32-bit targets and 64 bytes on 64-bit targets. |
| The default value is target-specific. |
| |
| `-G NUM' |
| On embedded PowerPC systems, put global and static items less than |
| or equal to NUM bytes into the small data or bss sections instead |
| of the normal data or bss section. By default, NUM is 8. The `-G |
| NUM' switch is also passed to the linker. All modules should be |
| compiled with the same `-G NUM' value. |
| |
| `-mregnames' |
| `-mno-regnames' |
| On System V.4 and embedded PowerPC systems do (do not) emit |
| register names in the assembly language output using symbolic |
| forms. |
| |
| `-mlongcall' |
| `-mno-longcall' |
| By default assume that all calls are far away so that a longer 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. |
| |
| `-mtls-markers' |
| `-mno-tls-markers' |
| Mark (do not mark) calls to `__tls_get_addr' with a relocation |
| specifying the function argument. The relocation allows ld to |
| reliably associate function call with argument setup instructions |
| for TLS optimization, which in turn allows gcc to better schedule |
| the sequence. |
| |
| `-pthread' |
| Adds support for multithreading with the "pthreads" library. This |
| option sets flags for both the preprocessor and linker. |
| |
| `-mrecip' |
| `-mno-recip' |
| This option will enable GCC to use the reciprocal estimate and |
| reciprocal square root estimate instructions with additional |
| Newton-Raphson steps to increase precision instead of doing a |
| divide or square root and divide for floating point arguments. |
| You should use the `-ffast-math' option when using `-mrecip' (or at |
| least `-funsafe-math-optimizations', `-finite-math-only', |
| `-freciprocal-math' and `-fno-trapping-math'). Note that while |
| the throughput of the sequence is generally higher than the |
| throughput of the non-reciprocal instruction, the precision of the |
| sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0 |
| equals 0.99999994) for reciprocal square roots. |
| |
| `-mrecip=OPT' |
| This option allows to control which reciprocal estimate |
| instructions may be used. OPT is a comma separated list of |
| options, that may be preceded by a `!' to invert the option: |
| `all': enable all estimate instructions, `default': enable the |
| default instructions, equivalent to `-mrecip', `none': disable all |
| estimate instructions, equivalent to `-mno-recip'; `div': enable |
| the reciprocal approximation instructions for both single and |
| double precision; `divf': enable the single precision reciprocal |
| approximation instructions; `divd': enable the double precision |
| reciprocal approximation instructions; `rsqrt': enable the |
| reciprocal square root approximation instructions for both single |
| and double precision; `rsqrtf': enable the single precision |
| reciprocal square root approximation instructions; `rsqrtd': |
| enable the double precision reciprocal square root approximation |
| instructions; |
| |
| So for example, `-mrecip=all,!rsqrtd' would enable the all of the |
| reciprocal estimate instructions, except for the `FRSQRTE', |
| `XSRSQRTEDP', and `XVRSQRTEDP' instructions which handle the |
| double precision reciprocal square root calculations. |
| |
| `-mrecip-precision' |
| `-mno-recip-precision' |
| Assume (do not assume) that the reciprocal estimate instructions |
| provide higher precision estimates than is mandated by the powerpc |
| ABI. Selecting `-mcpu=power6' or `-mcpu=power7' automatically |
| selects `-mrecip-precision'. The double precision square root |
| estimate instructions are not generated by default on low |
| precision machines, since they do not provide an estimate that |
| converges after three steps. |
| |
| `-mveclibabi=TYPE' |
| Specifies the ABI type to use for vectorizing intrinsics using an |
| external library. The only type supported at present is `mass', |
| which specifies to use IBM's Mathematical Acceleration Subsystem |
| (MASS) libraries for vectorizing intrinsics using external |
| libraries. GCC will currently emit calls to `acosd2', `acosf4', |
| `acoshd2', `acoshf4', `asind2', `asinf4', `asinhd2', `asinhf4', |
| `atan2d2', `atan2f4', `atand2', `atanf4', `atanhd2', `atanhf4', |
| `cbrtd2', `cbrtf4', `cosd2', `cosf4', `coshd2', `coshf4', |
| `erfcd2', `erfcf4', `erfd2', `erff4', `exp2d2', `exp2f4', `expd2', |
| `expf4', `expm1d2', `expm1f4', `hypotd2', `hypotf4', `lgammad2', |
| `lgammaf4', `log10d2', `log10f4', `log1pd2', `log1pf4', `log2d2', |
| `log2f4', `logd2', `logf4', `powd2', `powf4', `sind2', `sinf4', |
| `sinhd2', `sinhf4', `sqrtd2', `sqrtf4', `tand2', `tanf4', |
| `tanhd2', and `tanhf4' when generating code for power7. Both |
| `-ftree-vectorize' and `-funsafe-math-optimizations' have to be |
| enabled. The MASS libraries will have to be specified at link |
| time. |
| |
| `-mfriz' |
| `-mno-friz' |
| Generate (do not generate) the `friz' instruction when the |
| `-funsafe-math-optimizations' option is used to optimize rounding |
| a floating point value to 64-bit integer and back to floating |
| point. The `friz' instruction does not return the same value if |
| the floating point number is too large to fit in an integer. |
| |
| |
| File: gcc.info, Node: RX Options, Next: S/390 and zSeries Options, Prev: RS/6000 and PowerPC Options, Up: Submodel Options |
| |
| 3.17.34 RX Options |
| ------------------ |
| |
| These command line options are defined for RX targets: |
| |
| `-m64bit-doubles' |
| `-m32bit-doubles' |
| Make the `double' data type be 64-bits (`-m64bit-doubles') or |
| 32-bits (`-m32bit-doubles') in size. The default is |
| `-m32bit-doubles'. _Note_ RX floating point hardware only works |
| on 32-bit values, which is why the default is `-m32bit-doubles'. |
| |
| `-fpu' |
| `-nofpu' |
| Enables (`-fpu') or disables (`-nofpu') the use of RX floating |
| point hardware. The default is enabled for the RX600 series and |
| disabled for the RX200 series. |
| |
| Floating point instructions will only be generated for 32-bit |
| floating point values however, so if the `-m64bit-doubles' option |
| is in use then the FPU hardware will not be used for doubles. |
| |
| _Note_ If the `-fpu' option is enabled then |
| `-funsafe-math-optimizations' is also enabled automatically. This |
| is because the RX FPU instructions are themselves unsafe. |
| |
| `-mcpu=NAME' |
| Selects the type of RX CPU to be targeted. Currently three types |
| are supported, the generic RX600 and RX200 series hardware and the |
| specific RX610 CPU. The default is RX600. |
| |
| The only difference between RX600 and RX610 is that the RX610 does |
| not support the `MVTIPL' instruction. |
| |
| The RX200 series does not have a hardware floating point unit and |
| so `-nofpu' is enabled by default when this type is selected. |
| |
| `-mbig-endian-data' |
| `-mlittle-endian-data' |
| Store data (but not code) in the big-endian format. The default is |
| `-mlittle-endian-data', i.e. to store data in the little endian |
| format. |
| |
| `-msmall-data-limit=N' |
| Specifies the maximum size in bytes of global and static variables |
| which can be placed into the small data area. Using the small data |
| area can lead to smaller and faster code, but the size of area is |
| limited and it is up to the programmer to ensure that the area does |
| not overflow. Also when the small data area is used one of the |
| RX's registers (`r13') is reserved for use pointing to this area, |
| so it is no longer available for use by the compiler. This could |
| result in slower and/or larger code if variables which once could |
| have been held in `r13' are now pushed onto the stack. |
| |
| Note, common variables (variables which have not been initialised) |
| and constants are not placed into the small data area as they are |
| assigned to other sections in the output executable. |
| |
| The default value is zero, which disables this feature. Note, this |
| feature is not enabled by default with higher optimization levels |
| (`-O2' etc) because of the potentially detrimental effects of |
| reserving register `r13'. It is up to the programmer to |
| experiment and discover whether this feature is of benefit to their |
| program. |
| |
| `-msim' |
| `-mno-sim' |
| Use the simulator runtime. The default is to use the libgloss |
| board specific runtime. |
| |
| `-mas100-syntax' |
| `-mno-as100-syntax' |
| When generating assembler output use a syntax that is compatible |
| with Renesas's AS100 assembler. This syntax can also be handled |
| by the GAS assembler but it has some restrictions so generating it |
| is not the default option. |
| |
| `-mmax-constant-size=N' |
| Specifies the maximum size, in bytes, of a constant that can be |
| used as an operand in a RX instruction. Although the RX |
| instruction set does allow constants of up to 4 bytes in length to |
| be used in instructions, a longer value equates to a longer |
| instruction. Thus in some circumstances it can be beneficial to |
| restrict the size of constants that are used in instructions. |
| Constants that are too big are instead placed into a constant pool |
| and referenced via register indirection. |
| |
| The value N can be between 0 and 4. A value of 0 (the default) or |
| 4 means that constants of any size are allowed. |
| |
| `-mrelax' |
| Enable linker relaxation. Linker relaxation is a process whereby |
| the linker will attempt to reduce the size of a program by finding |
| shorter versions of various instructions. Disabled by default. |
| |
| `-mint-register=N' |
| Specify the number of registers to reserve for fast interrupt |
| handler functions. The value N can be between 0 and 4. A value |
| of 1 means that register `r13' will be reserved for the exclusive |
| use of fast interrupt handlers. A value of 2 reserves `r13' and |
| `r12'. A value of 3 reserves `r13', `r12' and `r11', and a value |
| of 4 reserves `r13' through `r10'. A value of 0, the default, |
| does not reserve any registers. |
| |
| `-msave-acc-in-interrupts' |
| Specifies that interrupt handler functions should preserve the |
| accumulator register. This is only necessary if normal code might |
| use the accumulator register, for example because it performs |
| 64-bit multiplications. The default is to ignore the accumulator |
| as this makes the interrupt handlers faster. |
| |
| |
| _Note:_ The generic GCC command line `-ffixed-REG' has special |
| significance to the RX port when used with the `interrupt' function |
| attribute. This attribute indicates a function intended to process |
| fast interrupts. GCC will will ensure that it only uses the registers |
| `r10', `r11', `r12' and/or `r13' and only provided that the normal use |
| of the corresponding registers have been restricted via the |
| `-ffixed-REG' or `-mint-register' command line options. |
| |
| |
| File: gcc.info, Node: S/390 and zSeries Options, Next: Score Options, Prev: RX Options, Up: Submodel Options |
| |
| 3.17.35 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. |
| |
| |
| File: gcc.info, Node: Score Options, Next: SH Options, Prev: S/390 and zSeries Options, Up: Submodel Options |
| |
| 3.17.36 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. |
| |
| |
| File: gcc.info, Node: SH Options, Next: Solaris 2 Options, Prev: Score Options, Up: Submodel Options |
| |
| 3.17.37 SH Options |
| ------------------ |
| |
| These `-m' options are defined for the SH implementations: |
| |
| `-m1' |
| Generate code for the SH1. |
| |
| `-m2' |
| Generate code for the SH2. |
| |
| `-m2e' |
| Generate code for the SH2e. |
| |
| `-m2a-nofpu' |
| Generate code for the SH2a without FPU, or for a SH2a-FPU in such |
| a way that the floating-point unit is not used. |
| |
| `-m2a-single-only' |
| Generate code for the SH2a-FPU, in such a way that no |
| double-precision floating point operations are used. |
| |
| `-m2a-single' |
| Generate code for the SH2a-FPU assuming the floating-point unit is |
| in single-precision mode by default. |
| |
| `-m2a' |
| Generate code for the SH2a-FPU assuming the floating-point unit is |
| in double-precision mode by default. |
| |
| `-m3' |
| Generate code for the SH3. |
| |
| `-m3e' |
| Generate code for the SH3e. |
| |
| `-m4-nofpu' |
| Generate code for the SH4 without a floating-point unit. |
| |
| `-m4-single-only' |
| Generate code for the SH4 with a floating-point unit that only |
| supports single-precision arithmetic. |
| |
| `-m4-single' |
| Generate code for the SH4 assuming the floating-point unit is in |
| single-precision mode by default. |
| |
| `-m4' |
| Generate code for the SH4. |
| |
| `-m4a-nofpu' |
| Generate code for the SH4al-dsp, or for a SH4a in such a way that |
| the floating-point unit is not used. |
| |
| `-m4a-single-only' |
| Generate code for the SH4a, in such a way that no double-precision |
| floating point operations are used. |
| |
| `-m4a-single' |
| Generate code for the SH4a assuming the floating-point unit is in |
| single-precision mode by default. |
| |
| `-m4a' |
| Generate code for the SH4a. |
| |
| `-m4al' |
| Same as `-m4a-nofpu', except that it implicitly passes `-dsp' to |
| the assembler. GCC doesn't generate any DSP instructions at the |
| moment. |
| |
| `-mb' |
| Compile code for the processor in big endian mode. |
| |
| `-ml' |
| Compile code for the processor in little endian mode. |
| |
| `-mdalign' |
| Align doubles at 64-bit boundaries. Note that this changes the |
| calling conventions, and thus some functions from the standard C |
| library 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'. Check `-mdalign' for |
| alignment constraints. |
| |
| `-mhitachi' |
| Comply with the calling conventions defined by Renesas. |
| |
| `-mrenesas' |
| Comply with the calling conventions defined by Renesas. |
| |
| `-mno-renesas' |
| Comply with the calling conventions defined for GCC before the |
| Renesas conventions were available. This option is the default |
| for all targets of the SH toolchain 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. |
| |
| `-maccumulate-outgoing-args' |
| Reserve space once for outgoing arguments in the function prologue |
| rather than around each call. Generally beneficial for |
| performance and size. Also needed for unwinding to avoid changing |
| the stack frame around conditional code. |
| |
| `-mdivsi3_libfunc=NAME' |
| Set the name of the library function used for 32 bit signed |
| division to NAME. This only 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'. |
| |
| |
| File: gcc.info, Node: Solaris 2 Options, Next: SPARC Options, Prev: SH Options, Up: Submodel Options |
| |
| 3.17.38 Solaris 2 Options |
| ------------------------- |
| |
| These `-m' options are supported on Solaris 2: |
| |
| `-mimpure-text' |
| `-mimpure-text', used in addition to `-shared', tells the compiler |
| to not pass `-z text' to the linker when linking a shared object. |
| Using this option, you can link position-dependent code into a |
| shared object. |
| |
| `-mimpure-text' suppresses the "relocations remain against |
| allocatable but non-writable sections" linker error message. |
| However, the necessary relocations 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'. |
| |
| |
| These switches are supported in addition to the above on Solaris 2: |
| |
| `-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'. |
| |
| |
| File: gcc.info, Node: SPARC Options, Next: SPU Options, Prev: Solaris 2 Options, Up: Submodel Options |
| |
| 3.17.39 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. |
| |
| `-mcpu=CPU_TYPE' |
| Set the instruction set, register set, and instruction scheduling |
| parameters for machine type CPU_TYPE. Supported values for |
| CPU_TYPE are `v7', `cypress', `v8', `supersparc', `hypersparc', |
| `leon', `sparclite', `f930', `f934', `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, leon |
| 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', `leon', `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'. |
| |
| `-mfix-at697f' |
| Enable the documented workaround for the single erratum of the |
| Atmel AT697F processor (which corresponds to erratum #13 of the |
| AT697E processor). |
| |
| 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. |
| |
| |
| File: gcc.info, Node: SPU Options, Next: System V Options, Prev: SPARC Options, Up: Submodel Options |
| |
| 3.17.40 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. |
| |
| `-mea32' |
| `-mea64' |
| Compile code assuming that pointers to the PPU address space |
| accessed via the `__ea' named address space qualifier are either |
| 32 or 64 bits wide. The default is 32 bits. As this is an ABI |
| changing option, all object code in an executable must be compiled |
| with the same setting. |
| |
| `-maddress-space-conversion' |
| `-mno-address-space-conversion' |
| Allow/disallow treating the `__ea' address space as superset of |
| the generic address space. This enables explicit type casts |
| between `__ea' and generic pointer as well as implicit conversions |
| of generic pointers to `__ea' pointers. The default is to allow |
| address space pointer conversions. |
| |
| `-mcache-size=CACHE-SIZE' |
| This option controls the version of libgcc that the compiler links |
| to an executable and selects a software-managed cache for |
| accessing variables in the `__ea' address space with a particular |
| cache size. Possible options for CACHE-SIZE are `8', `16', `32', |
| `64' and `128'. The default cache size is 64KB. |
| |
| `-matomic-updates' |
| `-mno-atomic-updates' |
| This option controls the version of libgcc that the compiler links |
| to an executable and selects whether atomic updates to the |
| software-managed cache of PPU-side variables are used. If you use |
| atomic updates, changes to a PPU variable from SPU code using the |
| `__ea' named address space qualifier will not interfere with |
| changes to other PPU variables residing in the same cache line |
| from PPU code. If you do not use atomic updates, such |
| interference may occur; however, writing back cache lines will be |
| more efficient. The default behavior is to use atomic updates. |
| |
| `-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. |
| |
| |
| |
| File: gcc.info, Node: System V Options, Next: V850 Options, Prev: SPU Options, Up: Submodel Options |
| |
| 3.17.41 Options for System V |
| ---------------------------- |
| |
| These additional options are available on System V Release 4 for |
| compatibility with other compilers on those systems: |
| |
| `-G' |
| Create a shared object. It is recommended that `-symbolic' or |
| `-shared' be used instead. |
| |
| `-Qy' |
| Identify the versions of each tool used by the compiler, in a |
| `.ident' assembler directive in the output. |
| |
| `-Qn' |
| Refrain from adding `.ident' directives to the output file (this is |
| the default). |
| |
| `-YP,DIRS' |
| Search the directories DIRS, and no others, for libraries |
| specified with `-l'. |
| |
| `-Ym,DIR' |
| Look in the directory DIR to find the M4 preprocessor. The |
| assembler uses this option. |
| |
| |
| File: gcc.info, Node: V850 Options, Next: VAX Options, Prev: System V Options, Up: Submodel Options |
| |
| 3.17.42 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. |
| |
| `-mv850e2v3' |
| Specify that the target processor is the V850E2V3. The |
| preprocessor constants `__v850e2v3__' will be defined if this |
| option is used. |
| |
| `-mv850e2' |
| Specify that the target processor is the V850E2. The preprocessor |
| constants `__v850e2__' will be defined if |
| |
| `-mv850e1' |
| Specify that the target processor is the V850E1. The preprocessor |
| constants `__v850e1__' and `__v850e__' will be defined if |
| |
| `-mv850es' |
| Specify that the target processor is the V850ES. This is an alias |
| for the `-mv850e1' option. |
| |
| `-mv850e' |
| Specify that the target processor is the V850E. The preprocessor |
| constant `__v850e__' will be defined if this option is used. |
| |
| If neither `-mv850' nor `-mv850e' nor `-mv850e1' nor `-mv850e2' |
| nor `-mv850e2v3' 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, v850e1, v850e2 and v850e2v3 flavors of the v850 |
| architecture. The default is `-mno-disable-callt' which allows |
| the CALLT instruction to be used. |
| |
| |
| |
| File: gcc.info, Node: VAX Options, Next: VxWorks Options, Prev: V850 Options, Up: Submodel Options |
| |
| 3.17.43 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. |
| |
| |
| File: gcc.info, Node: VxWorks Options, Next: x86-64 Options, Prev: VAX Options, Up: Submodel Options |
| |
| 3.17.44 VxWorks Options |
| ----------------------- |
| |
| The options in this section are defined for all VxWorks targets. |
| Options specific to the target hardware are listed with the other |
| options for that target. |
| |
| `-mrtp' |
| GCC can generate code for both VxWorks kernels and real time |
| processes (RTPs). This option switches from the former to the |
| latter. It also defines the preprocessor macro `__RTP__'. |
| |
| `-non-static' |
| Link an RTP executable against shared libraries rather than static |
| libraries. The options `-static' and `-shared' can also be used |
| for RTPs (*note Link Options::); `-static' is the default. |
| |
| `-Bstatic' |
| `-Bdynamic' |
| These options are passed down to the linker. They are defined for |
| compatibility with Diab. |
| |
| `-Xbind-lazy' |
| Enable lazy binding of function calls. This option is equivalent |
| to `-Wl,-z,now' and is defined for compatibility with Diab. |
| |
| `-Xbind-now' |
| Disable lazy binding of function calls. This option is the |
| default and is defined for compatibility with Diab. |
| |
| |
| File: gcc.info, Node: x86-64 Options, Next: Xstormy16 Options, Prev: VxWorks Options, Up: Submodel Options |
| |
| 3.17.45 x86-64 Options |
| ---------------------- |
| |
| These are listed under *Note i386 and x86-64 Options::. |
| |
| |
| File: gcc.info, Node: Xstormy16 Options, Next: Xtensa Options, Prev: x86-64 Options, Up: Submodel Options |
| |
| 3.17.46 Xstormy16 Options |
| ------------------------- |
| |
| These options are defined for Xstormy16: |
| |
| `-msim' |
| Choose startup files and linker script suitable for the simulator. |
| |
| |
| File: gcc.info, Node: Xtensa Options, Next: zSeries Options, Prev: Xstormy16 Options, Up: Submodel Options |
| |
| 3.17.47 Xtensa Options |
| ---------------------- |
| |
| These options are supported for Xtensa targets: |
| |
| `-mconst16' |
| `-mno-const16' |
| Enable or disable use of `CONST16' instructions for loading |
| constant values. The `CONST16' instruction is currently not a |
| standard option from Tensilica. When enabled, `CONST16' |
| instructions are always used in place of the standard `L32R' |
| instructions. The use of `CONST16' is enabled by default only if |
| the `L32R' instruction is not available. |
| |
| `-mfused-madd' |
| `-mno-fused-madd' |
| Enable or disable use of fused multiply/add and multiply/subtract |
| instructions in the floating-point option. This has no effect if |
| the floating-point option is not also enabled. Disabling fused |
| multiply/add and multiply/subtract instructions forces the |
| compiler to use separate instructions for the multiply and |
| add/subtract operations. This may be desirable in some cases |
| where strict IEEE 754-compliant results are required: the fused |
| multiply add/subtract instructions do not round the intermediate |
| result, thereby producing results with _more_ bits of precision |
| than specified by the IEEE standard. Disabling fused multiply |
| add/subtract instructions also ensures that the program output is |
| not sensitive to the compiler's ability to combine multiply and |
| add/subtract operations. |
| |
| `-mserialize-volatile' |
| `-mno-serialize-volatile' |
| When this option is enabled, GCC inserts `MEMW' instructions before |
| `volatile' memory references to guarantee sequential consistency. |
| The default is `-mserialize-volatile'. Use |
| `-mno-serialize-volatile' to omit the `MEMW' instructions. |
| |
| `-mforce-no-pic' |
| For targets, like GNU/Linux, where all user-mode Xtensa code must |
| be position-independent code (PIC), this option disables PIC for |
| compiling kernel code. |
| |
| `-mtext-section-literals' |
| `-mno-text-section-literals' |
| Control the treatment of literal pools. The default is |
| `-mno-text-section-literals', which places literals in a separate |
| section in the output file. This allows the literal pool to be |
| placed in a data RAM/ROM, and it also allows the linker to combine |
| literal pools from separate object files to remove redundant |
| literals and improve code size. With `-mtext-section-literals', |
| the literals are interspersed in the text section in order to keep |
| them as close as possible to their references. This may be |
| necessary for large assembly files. |
| |
| `-mtarget-align' |
| `-mno-target-align' |
| When this option is enabled, GCC instructs the assembler to |
| automatically align instructions to reduce branch penalties at the |
| expense of some code density. The assembler attempts to widen |
| density instructions to align branch targets and the instructions |
| following call instructions. If there are not enough preceding |
| safe density instructions to align a target, no widening 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. |
| |
| |
| File: gcc.info, Node: zSeries Options, Prev: Xtensa Options, Up: Submodel Options |
| |
| 3.17.48 zSeries Options |
| ----------------------- |
| |
| These are listed under *Note S/390 and zSeries Options::. |
| |
| |
| File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC |
| |
| 3.18 Options for Code Generation Conventions |
| ============================================ |
| |
| These machine-independent options control the interface conventions |
| used in code generation. |
| |
| Most of them have both positive and negative forms; the negative form |
| of `-ffoo' 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. For C99 and C++ extended identifiers, |
| the function name must be given in UTF-8, not using universal |
| character names. |
| |
| `-fstack-check' |
| Generate code to verify that you do not go beyond the boundary of |
| the stack. You should specify this flag if you are running in an |
| environment with multiple threads, but 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. |
| |
| `-fsplit-stack' |
| Generate code to automatically split the stack before it overflows. |
| The resulting program has a discontiguous stack which can only |
| overflow if the program is unable to allocate any more memory. |
| This is most useful when running threaded programs, as it is no |
| longer necessary to calculate a good stack size to use for each |
| thread. This is currently only implemented for the i386 and |
| x86_64 backends running GNU/Linux. |
| |
| When code compiled with `-fsplit-stack' calls code compiled |
| without `-fsplit-stack', there may not be much stack space |
| available for the latter code to run. If compiling all code, |
| including library code, with `-fsplit-stack' is not an option, |
| then the linker can fix up these calls so that the code compiled |
| without `-fsplit-stack' always has a large stack. Support for |
| this is implemented in the gold linker in GNU binutils release 2.21 |
| and later. |
| |
| `-fleading-underscore' |
| This option and its counterpart, `-fno-leading-underscore', |
| forcibly change the way C symbols are represented in the object |
| file. One use is to help link with legacy assembly code. |
| |
| *Warning:* the `-fleading-underscore' switch causes GCC to |
| generate code that is not binary compatible with code generated |
| without that switch. Use it to conform to a non-default |
| application binary interface. Not all targets provide complete |
| support for this switch. |
| |
| `-ftls-model=MODEL' |
| Alter the thread-local storage model to be used (*note |
| Thread-Local::). The MODEL argument should be one of |
| `global-dynamic', `local-dynamic', `initial-exec' or `local-exec'. |
| |
| 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; i.e., |
| available to be linked against from outside the shared object. |
| `protected' and `internal' are pretty useless in real-world usage |
| so the only other commonly used option 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; i.e., |
| declarations only for use within the local DSO should *always* be |
| marked explicitly as hidden as so to avoid PLT indirection |
| overheads--making this abundantly clear also aids readability and |
| self-documentation of the code. Note that due to ISO C++ |
| specification requirements, operator new and operator delete must |
| always be of default visibility. |
| |
| Be aware that headers from outside your project, in particular |
| system headers and headers from any other library you use, may not |
| be expecting to be compiled with visibility other than the |
| default. You may need to explicitly say `#pragma GCC visibility |
| push(default)' before including any such headers. |
| |
| `extern' declarations are not affected by `-fvisibility', so a lot |
| of code can be recompiled with `-fvisibility=hidden' with no |
| modifications. However, this means that calls to `extern' |
| functions with no explicit visibility 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'. |
| |
| `-fstrict-volatile-bitfields' |
| This option should be used if accesses to volatile bitfields (or |
| other structure fields, although the compiler usually honors those |
| types anyway) should use a single access of the width of the |
| field's type, aligned to a natural alignment if possible. For |
| example, targets with memory-mapped peripheral registers might |
| require all such accesses to be 16 bits wide; with this flag the |
| user could declare all peripheral bitfields as "unsigned short" |
| (assuming short is 16 bits on these targets) to force GCC to use |
| 16 bit accesses instead of, perhaps, a more efficient 32 bit |
| access. |
| |
| If this option is disabled, the compiler will use the most |
| efficient instruction. In the previous example, that might be a |
| 32-bit load instruction, even though that will access bytes that |
| do not contain any portion of the bitfield, or memory-mapped |
| registers unrelated to the one being updated. |
| |
| If the target requires strict alignment, and honoring the field |
| type would require violating this alignment, a warning is issued. |
| If the field has `packed' attribute, the access is done without |
| honoring the field type. If the field doesn't have `packed' |
| attribute, the access is done honoring the field type. In both |
| cases, GCC assumes that the user knows something about the target |
| hardware that it is unaware of. |
| |
| The default value of this option is determined by the application |
| binary interface for the target processor. |
| |
| |
| |
| 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::. |
| |
| |
| File: gcc.info, Node: Precompiled Headers, Prev: Environment Variables, Up: Invoking GCC |
| |
| 3.20 Using Precompiled Headers |
| ============================== |
| |
| Often large projects have many header files that are included in every |
| source file. The time the compiler takes to process these header files |
| over and over again can account for nearly all of the time required to |
| build the project. To make builds faster, GCC allows 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. |
| |
| |
| 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:: |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| File: gcc.info, Node: Declarators implementation, Next: Statements implementation, Prev: Qualifiers implementation, Up: C Implementation |
| |
| 4.11 Declarators |
| ================ |
| |
| * `The maximum number of declarators that may modify an arithmetic, |
| structure or union type (C90 6.5.4).' |
| |
| GCC is only limited by available memory. |
| |
| |
| |
| File: gcc.info, Node: Statements implementation, Next: Preprocessing directives implementation, Prev: Declarators implementation, Up: C Implementation |
| |
| 4.12 Statements |
| =============== |
| |
| * `The maximum number of `case' values in a `switch' statement (C90 |
| 6.6.4.2).' |
| |
| GCC is only limited by available memory. |
| |
| |
| |
| File: gcc.info, Node: Preprocessing directives implementation, Next: Library functions implementation, Prev: Statements implementation, Up: C Implementation |
| |
| 4.13 Preprocessing directives |
| ============================= |
| |
| *Note Implementation-defined behavior: (cpp)Implementation-defined |
| behavior, for details of these aspects of implementation-defined |
| behavior. |
| |
| * `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).' |
| |
| |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| |
| |
| File: gcc.info, Node: Locale-specific behavior implementation, Prev: Architecture implementation, Up: C Implementation |
| |
| 4.16 Locale-specific behavior |
| ============================= |
| |
| The behavior of these points are dependent on the implementation of the |
| C library, and are not defined by GCC itself. |
| |
| |
| File: gcc.info, Node: C++ Implementation, Next: C++ Extensions, Prev: C Extensions, Up: Top |
| |
| 5 C++ Implementation-defined behavior |
| ************************************* |
| |
| A conforming implementation of ISO C++ is required to document its |
| choice of behavior in each of the areas that are designated |
| "implementation defined". The following lists all such areas, along |
| with the section numbers from the ISO/IEC 14822:1998 and ISO/IEC |
| 14822:2003 standards. Some areas are only implementation-defined in |
| one version of the standard. |
| |
| Some choices depend on the externally determined ABI for the platform |
| (including standard character encodings) which GCC follows; these are |
| listed as "determined by ABI" below. *Note Binary Compatibility: |
| Compatibility, and `http://gcc.gnu.org/readings.html'. Some choices |
| are documented in the preprocessor manual. *Note |
| Implementation-defined behavior: (cpp)Implementation-defined behavior. |
| Some choices are documented in the corresponding document for the C |
| language. *Note C Implementation::. Some choices are made by the |
| library and operating system (or other environment when compiling for a |
| freestanding environment); refer to their documentation for details. |
| |
| * Menu: |
| |
| * Conditionally-supported behavior:: |
| * Exception handling:: |
| |
| |
| File: gcc.info, Node: Conditionally-supported behavior, Next: Exception handling, Up: C++ Implementation |
| |
| 5.1 Conditionally-supported behavior |
| ==================================== |
| |
| `Each implementation shall include documentation that identifies all |
| conditionally-supported constructs that it does not support (C++0x |
| 1.4).' |
| |
| * `Whether an argument of class type with a non-trivial copy |
| constructor or destructor can be passed to ... (C++0x 5.2.2).' |
| |
| Such argument passing is not supported. |
| |
| |
| |
| File: gcc.info, Node: Exception handling, Prev: Conditionally-supported behavior, Up: C++ Implementation |
| |
| 5.2 Exception handling |
| ====================== |
| |
| * `In the situation where no matching handler is found, it is |
| implementation-defined whether or not the stack is unwound before |
| std::terminate() is called (C++98 15.5.1).' |
| |
| The stack is not unwound before std::terminate is called. |
| |
| |
| |
| File: gcc.info, Node: C Extensions, Next: C++ Implementation, Prev: C Implementation, Up: Top |
| |
| 6 Extensions to the C Language Family |
| ************************************* |
| |
| GNU C provides several language features not found in ISO standard C. |
| (The `-pedantic' option directs GCC to print a warning message if any |
| of these features is used.) To test for the availability of these |
| features in conditional compilation, check for a predefined macro |
| `__GNUC__', which is always defined under GCC. |
| |
| These extensions are available in C and Objective-C. Most of them are |
| also available in C++. *Note Extensions to the C++ Language: C++ |
| Extensions, for extensions that apply _only_ to C++. |
| |
| Some features that are in ISO C99 but not C90 or C++ are also, as |
| extensions, accepted by GCC in C90 mode and in C++. |
| |
| * Menu: |
| |
| * Statement Exprs:: Putting statements and declarations inside expressions. |
| * Local Labels:: Labels local to a block. |
| * Labels as Values:: Getting pointers to labels, and computed gotos. |
| * Nested Functions:: As in Algol and Pascal, lexical scoping of functions. |
| * Constructing Calls:: Dispatching a call to another function. |
| * Typeof:: `typeof': referring to the type of an expression. |
| * Conditionals:: Omitting the middle operand of a `?:' expression. |
| * Long Long:: Double-word integers---`long long int'. |
| * __int128:: 128-bit integers---`__int128'. |
| * Complex:: Data types for complex numbers. |
| * Floating Types:: Additional Floating Types. |
| * Half-Precision:: Half-Precision Floating Point. |
| * Decimal Float:: Decimal Floating Types. |
| * Hex Floats:: Hexadecimal floating-point constants. |
| * Fixed-Point:: Fixed-Point Types. |
| * Named Address Spaces::Named address spaces. |
| * Zero Length:: Zero-length arrays. |
| * 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). |
| * Volatiles:: What constitutes an access to a volatile object. |
| * Extended Asm:: Assembler instructions with C expressions as operands. |
| (With them you can define ``built-in'' functions.) |
| * Constraints:: Constraints for asm operands |
| * Asm Labels:: Specifying the assembler name to use for a C symbol. |
| * Explicit Reg Vars:: Defining variables residing in specified registers. |
| * Alternate Keywords:: `__const__', `__asm__', etc., for header files. |
| * Incomplete Enums:: `enum foo;', with details to follow. |
| * Function Names:: Printable strings which are the name of the current |
| function. |
| * Return Address:: Getting the return or frame address of a function. |
| * Vector Extensions:: Using vector instructions through built-in functions. |
| * Offsetof:: Special syntax for implementing `offsetof'. |
| * 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. |
| |
| |
| File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions |
| |
| 6.1 Statements and Declarations in Expressions |
| ============================================== |
| |
| A compound statement enclosed in parentheses may appear as an expression |
| in GNU C. This allows you to use loops, switches, and local variables |
| within an expression. |
| |
| Recall that a compound statement is a sequence of statements surrounded |
| by braces; in this construct, parentheses go around the braces. For |
| example: |
| |
| ({ int y = foo (); int z; |
| if (y > 0) z = y; |
| else z = - y; |
| z; }) |
| |
| is a valid (though slightly more complex than necessary) expression for |
| the absolute value of `foo ()'. |
| |
| The last thing in the compound statement should be an expression |
| followed by a semicolon; the value of this subexpression serves as the |
| value of the entire construct. (If you use some other kind of statement |
| last within the braces, the construct has type `void', and thus |
| effectively no value.) |
| |
| This feature is especially useful in making macro definitions "safe" |
| (so that they evaluate each operand exactly once). For example, the |
| "maximum" function is commonly defined as a macro in standard C as |
| follows: |
| |
| #define max(a,b) ((a) > (b) ? (a) : (b)) |
| |
| But this definition computes either A or B twice, with bad results if |
| the operand has side effects. In GNU C, if you know the type of the |
| operands (here taken as `int'), you can define the macro safely as |
| follows: |
| |
| #define maxint(a,b) \ |
| ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) |
| |
| Embedded statements are not allowed in constant expressions, such as |
| the value of an enumeration constant, the width of a bit-field, or the |
| initial value of a static variable. |
| |
| If you don't know the type of the operand, you can still do this, but |
| you must use `typeof' (*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' |
| |
| |
| File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions |
| |
| 6.2 Locally Declared Labels |
| =========================== |
| |
| GCC allows you to declare "local labels" in any nested block scope. A |
| local label is just like an ordinary label, but you can only reference |
| it (with a `goto' statement, or by taking its address) within the block |
| in which it 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. |
| |
| |
| File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions |
| |
| 6.3 Labels as Values |
| ==================== |
| |
| You can get the address of a label defined in the current function (or |
| a containing function) with the unary operator `&&'. The value has |
| type `void *'. This value is a constant and can be used wherever a |
| constant of that type is valid. For example: |
| |
| void *ptr; |
| /* ... */ |
| ptr = &&foo; |
| |
| To use these values, you need to be able to jump to one. This is done |
| with the computed goto statement(1), `goto *EXP;'. For example, |
| |
| goto *ptr; |
| |
| Any expression of type `void *' is allowed. |
| |
| One way of using these constants is in initializing a static array that |
| 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__,__noclone__))' should be used to prevent |
| inlining and cloning. If `&&foo' is used in a static variable |
| initializer, inlining and cloning is forbidden. |
| |
| ---------- Footnotes ---------- |
| |
| (1) The analogous feature in Fortran is called an assigned goto, but |
| that name seems inappropriate in C, where one can do more than simply |
| store label addresses in label variables. |
| |
| |
| File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions |
| |
| 6.4 Nested Functions |
| ==================== |
| |
| A "nested function" is a function defined inside another function. |
| (Nested functions are 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". This technique was described in |
| `Lexical Closures for C++' (Thomas M. Breuel, USENIX C++ Conference |
| Proceedings, October 17-21, 1988). |
| |
| A nested function can jump to a label inherited from a containing |
| function, provided the label 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]; |
| } |
| /* ... */ |
| } |
| |
| |
| File: gcc.info, Node: Constructing Calls, Next: Typeof, Prev: Nested Functions, Up: C Extensions |
| |
| 6.5 Constructing Function Calls |
| =============================== |
| |
| Using the built-in functions described below, you can record the |
| arguments a function received, and call another function with the same |
| arguments, without knowing the number or types of the arguments. |
| |
| You can also record the return value of that function call, and later |
| return that value, without knowing what data type the function tried to |
| return (as long as your caller expects that data type). |
| |
| However, these built-in functions may interact badly with some |
| sophisticated features or other extensions of the language. It is, |
| therefore, not recommended to use them outside very simple functions |
| acting as mere forwarders for their arguments. |
| |
| -- Built-in Function: void * __builtin_apply_args () |
| This built-in function returns a pointer to data describing how to |
| perform a call with the same arguments as 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: size_t __builtin_va_arg_pack_len () |
| This built-in function returns the number of anonymous arguments of |
| an inline function. It can be used only in inline functions 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 |
| |
| |
| File: gcc.info, Node: Typeof, Next: Conditionals, Prev: Constructing Calls, Up: C Extensions |
| |
| 6.6 Referring to a Type with `typeof' |
| ===================================== |
| |
| Another way to refer to the type of an expression is with `typeof'. |
| The syntax of using of this keyword looks like `sizeof', but the |
| construct acts semantically like a type name defined with `typedef'. |
| |
| There are two ways of writing the argument to `typeof': with an |
| expression or with a type. Here is an example with an expression: |
| |
| typeof (x[0](1)) |
| |
| This assumes that `x' is an array of pointers to functions; the type |
| described is that of the values of the functions. |
| |
| Here is an example with a typename as the argument: |
| |
| typeof (int *) |
| |
| Here the type described is that of pointers to `int'. |
| |
| If you are writing a header file that must work when included in ISO C |
| programs, write `__typeof__' instead of `typeof'. *Note Alternate |
| Keywords::. |
| |
| A `typeof'-construct can be used anywhere a typedef name could be |
| used. For example, you can use it in a declaration, in a cast, or |
| inside of `sizeof' or `typeof'. |
| |
| The operand of `typeof' is evaluated for its side effects if and only |
| if it is an expression of variably modified type or the name of such a |
| type. |
| |
| `typeof' is often useful in conjunction with 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. |
| |
| |
| File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Typeof, Up: C Extensions |
| |
| 6.7 Conditionals with Omitted Operands |
| ====================================== |
| |
| The middle operand in a conditional expression may be omitted. Then if |
| the first operand is nonzero, its value is the value of the conditional |
| expression. |
| |
| Therefore, the expression |
| |
| x ? : y |
| |
| has the value of `x' if that is nonzero; otherwise, the value of `y'. |
| |
| This example is perfectly equivalent to |
| |
| x ? x : y |
| |
| In this simple case, the ability to omit the middle operand is not |
| especially useful. When it becomes useful is when the first operand |
| does, or may (if it is a macro argument), contain a side effect. Then |
| repeating the operand in the middle would perform the side effect |
| twice. Omitting the middle operand uses the value already computed |
| without the undesirable effects of recomputing it. |
| |
| |
| File: gcc.info, Node: __int128, Next: Complex, Prev: Long Long, Up: C Extensions |
| |
| 6.8 128-bits integers |
| ===================== |
| |
| As an extension the integer scalar type `__int128' is supported for |
| targets having an integer mode wide enough to hold 128-bit. Simply |
| write `__int128' for a signed 128-bit integer, or `unsigned __int128' |
| for an unsigned 128-bit integer. There is no support in GCC to express |
| an integer constant of type `__int128' for targets having `long long' |
| integer with less then 128 bit width. |
| |
| |
| File: gcc.info, Node: Long Long, Next: __int128, Prev: Conditionals, Up: C Extensions |
| |
| 6.9 Double-Word Integers |
| ======================== |
| |
| ISO C99 supports data types for integers that are at least 64 bits wide, |
| and as an extension GCC supports them in C90 mode and in C++. Simply |
| write `long long int' for a signed integer, or `unsigned long long int' |
| for an unsigned integer. To make an integer constant of type `long |
| long int', add the suffix `LL' to the integer. To make an integer |
| constant of type `unsigned long long int', add the suffix `ULL' to the |
| integer. |
| |
| You can use these types in arithmetic like any other integer types. |
| Addition, subtraction, and bitwise boolean operations on these types |
| are open-coded on all types of machines. Multiplication is open-coded |
| if the machine supports 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. |
| |
| |
| File: gcc.info, Node: Complex, Next: Floating Types, Prev: __int128, Up: C Extensions |
| |
| 6.10 Complex Numbers |
| ==================== |
| |
| ISO C99 supports complex floating data types, and as an extension GCC |
| supports them in C90 mode and in C++, 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. |
| |
| |
| File: gcc.info, Node: Floating Types, Next: Half-Precision, Prev: Complex, Up: C Extensions |
| |
| 6.11 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. |
| The `__float128' type is supported on hppa HP-UX targets. |
| |
| |
| File: gcc.info, Node: Half-Precision, Next: Decimal Float, Prev: Floating Types, Up: C Extensions |
| |
| 6.12 Half-Precision Floating Point |
| ================================== |
| |
| On ARM targets, GCC supports half-precision (16-bit) floating point via |
| the `__fp16' type. You must enable this type explicitly with the |
| `-mfp16-format' command-line option in order to use it. |
| |
| ARM supports two incompatible representations for half-precision |
| floating-point values. You must choose one of the representations and |
| use it consistently in your program. |
| |
| Specifying `-mfp16-format=ieee' selects the IEEE 754-2008 format. |
| This format can represent normalized values in the range of 2^-14 to |
| 65504. There are 11 bits of significand precision, approximately 3 |
| decimal digits. |
| |
| Specifying `-mfp16-format=alternative' selects the ARM alternative |
| format. This representation is similar to the IEEE format, but does |
| not support infinities or NaNs. Instead, the range of exponents is |
| extended, so that this format can represent normalized values in the |
| range of 2^-14 to 131008. |
| |
| The `__fp16' type is a storage format only. For purposes of |
| arithmetic and other operations, `__fp16' values in C or C++ |
| expressions are automatically promoted to `float'. In addition, you |
| cannot declare a function with a return value or parameters of type |
| `__fp16'. |
| |
| Note that conversions from `double' to `__fp16' involve an |
| intermediate conversion to `float'. Because of rounding, this can |
| sometimes produce a different result than a direct conversion. |
| |
| ARM provides hardware support for conversions between `__fp16' and |
| `float' values as an extension to VFP and NEON (Advanced SIMD). GCC |
| generates code using these hardware instructions if you compile with |
| options to select an FPU that provides them; for example, |
| `-mfpu=neon-fp16 -mfloat-abi=softfp', in addition to the |
| `-mfp16-format' option to select a half-precision format. |
| |
| Language-level support for the `__fp16' data type is independent of |
| whether GCC generates code using hardware floating-point instructions. |
| In cases where hardware support is not specified, GCC implements |
| conversions between `__fp16' and `float' values as library calls. |
| |
| |
| File: gcc.info, Node: Decimal Float, Next: Hex Floats, Prev: Half-Precision, Up: C Extensions |
| |
| 6.13 Decimal Floating Types |
| =========================== |
| |
| As an extension, 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: |
| |
| * 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. |
| |
| |
| File: gcc.info, Node: Hex Floats, Next: Fixed-Point, Prev: Decimal Float, Up: C Extensions |
| |
| 6.14 Hex Floats |
| =============== |
| |
| ISO C99 supports floating-point numbers written not only in the usual |
| decimal notation, such as `1.55e1', but also numbers such as `0x1.fp3' |
| written in hexadecimal format. As a GNU extension, GCC supports this |
| in C90 mode (except in some cases when strictly conforming) and in C++. |
| In that format the `0x' hex introducer and the `p' or `P' exponent |
| field are mandatory. The exponent is a decimal number that indicates |
| the power of 2 by which the significant part 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'. |
| |
| |
| File: gcc.info, Node: Fixed-Point, Next: Named Address Spaces, Prev: Hex Floats, Up: C Extensions |
| |
| 6.15 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. |
| |
| |
| File: gcc.info, Node: Named Address Spaces, Next: Zero Length, Prev: Fixed-Point, Up: C Extensions |
| |
| 6.16 Named address spaces |
| ========================= |
| |
| As an extension, the GNU C compiler supports named address spaces as |
| defined in the N1275 draft of ISO/IEC DTR 18037. Support for named |
| address spaces in GCC will evolve as the draft technical report changes. |
| Calling conventions for any target might also change. At present, only |
| the SPU and M32C targets support other address spaces. On the SPU |
| target, for example, variables may be declared as belonging to another |
| address space by qualifying the type with the `__ea' address space |
| identifier: |
| |
| extern int __ea i; |
| |
| When the variable `i' is accessed, the compiler will generate special |
| code to access this variable. It may use runtime library support, or |
| generate special machine instructions to access that address space. |
| |
| The `__ea' identifier may be used exactly like any other C type |
| qualifier (e.g., `const' or `volatile'). See the N1275 document for |
| more details. |
| |
| On the M32C target, with the R8C and M16C cpu variants, variables |
| qualified with `__far' are accessed using 32-bit addresses in order to |
| access memory beyond the first 64k bytes. If `__far' is used with the |
| M32CM or M32C cpu variants, it has no effect. |
| |
| |
| File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Named Address Spaces, Up: C Extensions |
| |
| 6.17 Arrays of Length Zero |
| ========================== |
| |
| Zero-length arrays are allowed in GNU C. They are very useful as the |
| last element of a structure 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. |
| |
| |
| File: gcc.info, Node: Empty Structures, Next: Variadic Macros, Prev: Variable Length, Up: C Extensions |
| |
| 6.18 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'. |
| |
| |
| File: gcc.info, Node: Variable Length, Next: Empty Structures, Prev: Zero Length, Up: C Extensions |
| |
| 6.19 Arrays of Variable Length |
| ============================== |
| |
| Variable-length automatic arrays are allowed in ISO C99, and as an |
| extension GCC accepts them in C90 mode and in C++. These arrays are |
| declared like any other automatic arrays, but with a length that is not |
| a constant expression. The storage is allocated at the point of |
| declaration and deallocated when the 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. |
| |
| |
| File: gcc.info, Node: Variadic Macros, Next: Escaped Newlines, Prev: Empty Structures, Up: C Extensions |
| |
| 6.20 Macros with a Variable Number of Arguments. |
| ================================================ |
| |
| In the ISO C standard of 1999, a macro can be declared to accept a |
| variable number of arguments much as a function can. The syntax for |
| defining the macro is similar to that of a function. Here is an |
| example: |
| |
| #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__) |
| |
| Here `...' is a "variable argument". In the invocation of such a |
| macro, it represents the zero or more tokens until the closing |
| parenthesis that ends the invocation, including any commas. This set of |
| tokens replaces the identifier `__VA_ARGS__' in the macro body wherever |
| it appears. See the CPP manual for more information. |
| |
| GCC has long supported variadic macros, and used a different syntax |
| that allowed you to give a name to the variable arguments just like any |
| other argument. Here is an example: |
| |
| #define debug(format, args...) fprintf (stderr, format, args) |
| |
| This is in all ways equivalent to the ISO C example above, but arguably |
| more readable and descriptive. |
| |
| GNU CPP has two further variadic macro extensions, and permits them to |
| be used with either of the above forms of macro definition. |
| |
| In standard C, you are not allowed to leave the variable argument out |
| entirely; but you are allowed to pass an empty argument. For example, |
| this invocation is invalid in ISO C, because there is no comma after |
| the string: |
| |
| debug ("A message") |
| |
| GNU CPP permits you to completely omit the variable arguments in this |
| way. In the above examples, the compiler would complain, though since |
| the expansion of the macro still has the extra comma after the format |
| string. |
| |
| To help solve this problem, CPP behaves specially for variable |
| arguments used with the token paste operator, `##'. If instead you |
| write |
| |
| #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__) |
| |
| and if the variable arguments are omitted or empty, the `##' operator |
| causes the preprocessor to remove the comma before it. If you do |
| provide some variable arguments in your macro invocation, GNU CPP does |
| not complain about the paste operation and instead places the variable |
| arguments after the comma. Just like any other pasted macro argument, |
| these arguments are not macro expanded. |
| |
| |
| File: gcc.info, Node: Escaped Newlines, Next: Subscripting, Prev: Variadic Macros, Up: C Extensions |
| |
| 6.21 Slightly Looser Rules for Escaped Newlines |
| =============================================== |
| |
| Recently, the preprocessor has relaxed its treatment of escaped |
| newlines. Previously, the newline had to immediately follow a |
| backslash. The current implementation allows whitespace in the form of |
| spaces, horizontal and vertical tabs, and form feeds between the |
| backslash and the subsequent newline. The preprocessor issues a |
| warning, but treats it as a valid escaped newline and combines the two |
| lines to form a single logical line. This works within comments and |
| tokens, as well as between tokens. Comments are _not_ treated as |
| whitespace for the purposes of this relaxation, since they have not yet |
| been replaced with spaces. |
| |
| |
| File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Escaped Newlines, Up: C Extensions |
| |
| 6.22 Non-Lvalue Arrays May Have Subscripts |
| ========================================== |
| |
| In ISO C99, arrays that are not lvalues still decay to pointers, and |
| may be subscripted, although they may not be modified or used after the |
| next sequence point and the unary `&' operator may not be applied to |
| them. As an extension, GCC allows such arrays to be subscripted in C90 |
| mode, though otherwise they do not decay to pointers outside C99 mode. |
| For example, this is valid in GNU C though not valid in C90: |
| |
| struct foo {int a[4];}; |
| |
| struct foo f(); |
| |
| bar (int index) |
| { |
| return f().a[index]; |
| } |
| |
| |
| File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: C Extensions |
| |
| 6.23 Arithmetic on `void'- and Function-Pointers |
| ================================================ |
| |
| In GNU C, addition and subtraction operations are supported on pointers |
| to `void' and on pointers to functions. This is done by treating the |
| size of a `void' or of a function as 1. |
| |
| A consequence of this is that `sizeof' is also allowed on `void' and |
| on function types, and returns 1. |
| |
| The option `-Wpointer-arith' requests a warning if these extensions |
| are used. |
| |
| |
| File: gcc.info, Node: Initializers, Next: Compound Literals, Prev: Pointer Arith, Up: C Extensions |
| |
| 6.24 Non-Constant Initializers |
| ============================== |
| |
| As in standard C++ and ISO C99, the elements of an aggregate |
| initializer for an automatic variable are not required to be constant |
| expressions in GNU C. Here is an example of an initializer with |
| run-time varying elements: |
| |
| foo (float f, float g) |
| { |
| float beat_freqs[2] = { f-g, f+g }; |
| /* ... */ |
| } |
| |
| |
| File: gcc.info, Node: Compound Literals, Next: Designated Inits, Prev: Initializers, Up: C Extensions |
| |
| 6.25 Compound Literals |
| ====================== |
| |
| ISO C99 supports compound literals. A compound literal looks like a |
| cast containing an initializer. Its value is an object of the type |
| specified in the cast, containing the elements specified in the |
| initializer; it is an lvalue. As an extension, GCC supports compound |
| literals in C90 mode and in C++. |
| |
| 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}; |
| |
| |
| File: gcc.info, Node: Designated Inits, Next: Cast to Union, Prev: Compound Literals, Up: C Extensions |
| |
| 6.26 Designated Initializers |
| ============================ |
| |
| Standard C90 requires the elements of an initializer to appear in a |
| fixed order, the same as the order of the elements in the array or |
| structure being initialized. |
| |
| In ISO C99 you can give the elements in any order, specifying the array |
| indices or structure field names they apply to, and GNU C allows this as |
| an extension in C90 mode as well. This extension is not implemented in |
| GNU C++. |
| |
| To specify an array index, write `[INDEX] =' before the element value. |
| For example, |
| |
| int a[6] = { [4] = 29, [2] = 15 }; |
| |
| is equivalent to |
| |
| int a[6] = { 0, 0, 15, 0, 29, 0 }; |
| |
| The index values must be constant expressions, even if the array being |
| initialized is automatic. |
| |
| An alternative syntax for this 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. |
| |
| |
| File: gcc.info, Node: Case Ranges, Next: Mixed Declarations, Prev: Cast to Union, Up: C Extensions |
| |
| 6.27 Case Ranges |
| ================ |
| |
| You can specify a range of consecutive values in a single `case' label, |
| like this: |
| |
| case LOW ... HIGH: |
| |
| This has the same effect as the proper number of individual `case' |
| labels, one for each integer value from LOW to HIGH, inclusive. |
| |
| This feature is especially useful for ranges of ASCII character codes: |
| |
| case 'A' ... 'Z': |
| |
| *Be careful:* Write spaces around the `...', for otherwise it may be |
| parsed wrong when you use it with integer values. For example, write |
| this: |
| |
| case 1 ... 5: |
| |
| rather than this: |
| |
| case 1...5: |
| |
| |
| File: gcc.info, Node: Cast to Union, Next: Case Ranges, Prev: Designated Inits, Up: C Extensions |
| |
| 6.28 Cast to a Union Type |
| ========================= |
| |
| A cast to union type is similar to other casts, except that the type |
| specified is a union type. You can specify the type either with `union |
| TAG' or with a typedef name. A cast to union is actually a constructor |
| 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); |
| |
| |
| File: gcc.info, Node: Mixed Declarations, Next: Function Attributes, Prev: Case Ranges, Up: C Extensions |
| |
| 6.29 Mixed Declarations and Code |
| ================================ |
| |
| ISO C99 and ISO C++ allow declarations and code to be freely mixed |
| within compound statements. As an extension, GCC also allows this in |
| C90 mode. For example, you could do: |
| |
| int i; |
| /* ... */ |
| i++; |
| int j = i + 2; |
| |
| Each identifier is visible from where it is declared until the end of |
| the enclosing block. |
| |
| |
| File: gcc.info, Node: Function Attributes, Next: Attribute Syntax, Prev: Mixed Declarations, Up: C Extensions |
| |
| 6.30 Declaring Attributes of Functions |
| ====================================== |
| |
| In GNU C, you declare certain things about functions called in your |
| program which help the compiler optimize function calls and check your |
| code more carefully. |
| |
| The keyword `__attribute__' allows you to specify special attributes |
| when making a declaration. This keyword is followed by an attribute |
| specification inside double parentheses. The following attributes are |
| currently defined for functions on all targets: `aligned', |
| `alloc_size', `noreturn', `returns_twice', `noinline', `noclone', |
| `always_inline', `flatten', `pure', `const', `nothrow', `sentinel', |
| `format', `format_arg', `no_instrument_function', `no_split_stack', |
| `section', `constructor', `destructor', `used', `unused', `deprecated', |
| `weak', `malloc', `alias', `ifunc', `warn_unused_result', `nonnull', |
| `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::). |
| |
| GCC plugins may provide their own attributes. |
| |
| You may also specify attributes with `__' preceding and following each |
| keyword. This allows you to use them in header files without being |
| concerned about a possible macro of the same name. For example, you |
| may use `__noreturn__' instead of `noreturn'. |
| |
| *Note Attribute Syntax::, for details of the exact syntax for using |
| attributes. |
| |
| `alias ("TARGET")' |
| The `alias' attribute causes the declaration to be emitted as an |
| alias for another symbol, which must be specified. For instance, |
| |
| void __f () { /* Do something. */; } |
| void f () __attribute__ ((weak, alias ("__f"))); |
| |
| defines `f' to be a weak alias for `__f'. In C++, the mangled |
| name for the target must be used. It is an error if `__f' is not |
| defined in the same translation unit. |
| |
| Not all target machines support this attribute. |
| |
| `aligned (ALIGNMENT)' |
| This attribute specifies a minimum alignment for the function, |
| measured in bytes. |
| |
| You cannot use this attribute to decrease the alignment of a |
| function, only to increase it. However, when you explicitly |
| specify a function alignment this 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 gnu90 mode even when compiling |
| in C99 or gnu99 mode. |
| |
| If the function is declared `extern', then this definition of the |
| function is used only for inlining. In no case is the function |
| compiled as a standalone function, not even if you take its address |
| explicitly. Such an address becomes an external reference, as if |
| you had only declared the function, and had not defined it. This |
| has almost the effect of a macro. The way to use this is to put a |
| function definition in a header file with this attribute, and put |
| another copy of the function, without `extern', in a library file. |
| The definition in the header file 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. |
| |
| `bank_switch' |
| When added to an interrupt handler with the M32C port, causes the |
| prologue and epilogue to use bank switching to preserve the |
| registers rather than saving them on the stack. |
| |
| `flatten' |
| Generally, inlining into a function is limited. For a function |
| marked with this attribute, every call inside this function 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' |
| `deprecated (MSG)' |
| The `deprecated' attribute results in a warning if the function is |
| used anywhere in the source file. This is useful when identifying |
| functions that are expected to be removed in a future version of a |
| program. The warning also includes the location of the declaration |
| of the deprecated function, to enable users to easily find further |
| information about why the function is deprecated, or what they |
| should do instead. Note that the warnings only occurs for uses: |
| |
| int old_fn () __attribute__ ((deprecated)); |
| int old_fn (); |
| int (*fn_ptr)() = old_fn; |
| |
| results in a warning on line 3 but not line 2. The optional msg |
| argument, which must be a string, will be printed in the warning if |
| present. |
| |
| The `deprecated' attribute can also be used for variables and |
| types (*note Variable Attributes::, *note Type Attributes::.) |
| |
| `disinterrupt' |
| On MeP targets, this attribute causes the compiler to emit |
| instructions to disable interrupts for the duration of the given |
| function. |
| |
| `dllexport' |
| On Microsoft Windows targets and Symbian OS targets the |
| `dllexport' attribute causes the compiler to provide a global |
| pointer to a pointer in a DLL, so that it can be referenced with |
| the `dllimport' attribute. On Microsoft Windows targets, the |
| pointer name is formed by combining `_imp__' and the function or |
| variable name. |
| |
| You can use `__declspec(dllexport)' as a synonym for |
| `__attribute__ ((dllexport))' for compatibility with other |
| compilers. |
| |
| On systems that support the `visibility' attribute, this attribute |
| also implies "default" visibility. It is an error to explicitly |
| specify any other visibility. |
| |
| In previous versions of GCC, the `dllexport' attribute was ignored |
| for inlined functions, unless the `-fkeep-inline-functions' flag |
| had been used. The default behaviour now is to emit all |
| dllexported inline functions; however, this can cause object |
| file-size bloat, in which case the old behaviour can be restored |
| by using `-fno-keep-inline-dllexport'. |
| |
| The attribute is also ignored for undefined symbols. |
| |
| When applied to C++ classes, the attribute marks defined |
| non-inlined member functions and static data members as exports. |
| Static consts initialized in-class are not marked unless they are |
| also defined out-of-class. |
| |
| For Microsoft Windows targets there are alternative methods for |
| including the symbol in the DLL's export table such as using a |
| `.def' file with an `EXPORTS' section or, with GNU ld, using the |
| `--export-all' linker flag. |
| |
| `dllimport' |
| On Microsoft Windows and Symbian OS targets, the `dllimport' |
| attribute causes the compiler to reference a function or variable |
| via a global pointer to a pointer that is set up by the DLL |
| exporting the symbol. The attribute implies `extern'. On |
| Microsoft Windows targets, the pointer name is formed by combining |
| `_imp__' and the function or variable name. |
| |
| You can use `__declspec(dllimport)' as a synonym for |
| `__attribute__ ((dllimport))' for compatibility with other |
| compilers. |
| |
| On systems that support the `visibility' attribute, this attribute |
| also implies "default" visibility. It is an error to explicitly |
| specify any other visibility. |
| |
| Currently, the attribute is ignored for inlined functions. If the |
| attribute is applied to a symbol _definition_, an error is |
| reported. If a symbol previously declared `dllimport' is later |
| defined, the attribute is ignored in subsequent references, and a |
| warning is emitted. The attribute is also overridden by a |
| subsequent declaration as `dllexport'. |
| |
| When applied to C++ classes, the attribute marks non-inlined |
| member functions and static data members as imports. However, the |
| attribute is ignored for virtual methods to allow creation of |
| vtables using thunks. |
| |
| On the SH Symbian OS target the `dllimport' attribute also has |
| another affect--it can cause the vtable and run-time type |
| information for a class to be exported. This happens when the |
| class has a dllimport'ed constructor or a non-inline, non-pure |
| virtual function and, for either of those two conditions, the |
| class also has an inline constructor or destructor and has a key |
| function that is defined in the current translation unit. |
| |
| For Microsoft Windows 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. If `-fwhole-program' is used together with `-flto' and |
| `gold' is used as the linker plugin, `externally_visible' |
| attributes are automatically added to functions (not variable yet |
| due to a current `gold' issue) that are accessed outside of LTO |
| objects according to resolution file produced by `gold'. For |
| other linkers that cannot generate resolution file, explicit |
| `externally_visible' attributes are still necessary. |
| |
| `far' |
| On 68HC11 and 68HC12 the `far' attribute causes the compiler to |
| use a calling convention that takes care of switching memory banks |
| when entering and leaving a function. This calling convention is |
| also the default when using the `-mlong-calls' option. |
| |
| On 68HC12 the compiler 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'. |
| |
| On MeP targets this causes the compiler to use a calling convention |
| which assumes the called function is too far away for the built-in |
| addressing modes. |
| |
| `fast_interrupt' |
| Use this attribute on the M32C and RX ports to indicate that the |
| specified function is a fast interrupt handler. This is just like |
| the `interrupt' attribute, except that `freit' is used to return |
| instead of `reit'. |
| |
| `fastcall' |
| On the Intel 386, the `fastcall' attribute causes the compiler to |
| pass the first argument (if of integral type) in the register ECX |
| and the second argument (if of integral type) in the register EDX. |
| Subsequent and other typed arguments are passed on the stack. The |
| called function will pop the arguments off the stack. If the |
| number of arguments is variable all arguments are pushed on the |
| stack. |
| |
| `thiscall' |
| On the Intel 386, the `thiscall' attribute causes the compiler to |
| pass the first argument (if of integral type) in the register ECX. |
| Subsequent and other typed arguments are passed on the stack. The |
| called function will pop the arguments off the stack. If the |
| number of arguments is variable all arguments are pushed on the |
| stack. The `thiscall' attribute is intended for C++ non-static |
| member functions. As gcc extension this calling convention can be |
| used for C-functions and for static member methods. |
| |
| `format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)' |
| The `format' attribute specifies that a function takes `printf', |
| `scanf', `strftime' or `strfmon' style arguments 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. |
| |
| For Objective-C dialects, `NSString' (or `__NSString__') is |
| recognized in the same context. Declarations including these |
| format attributes will be parsed for correct syntax, however the |
| result of checking of such format strings is not yet defined, and |
| will not be carried out by this version of the compiler. |
| |
| The target may also provide additional types of format checks. |
| *Note Format Checks Specific to Particular Target Machines: Target |
| Format Checks. |
| |
| `format_arg (STRING-INDEX)' |
| The `format_arg' attribute specifies that a function takes a format |
| string for a `printf', `scanf', `strftime' or `strfmon' style |
| function and modifies it (for example, to translate it into |
| another language), so the result can be passed to a `printf', |
| `scanf', `strftime' or `strfmon' style function (with the |
| remaining arguments to the format function the same as they would |
| have been for the unmodified string). For example, the |
| declaration: |
| |
| extern char * |
| my_dgettext (char *my_domain, const char *my_format) |
| __attribute__ ((format_arg (2))); |
| |
| causes the compiler to check the arguments in calls to a `printf', |
| `scanf', `strftime' or `strfmon' type function, whose format |
| string argument is a call to the `my_dgettext' function, for |
| consistency with the format string argument `my_format'. If the |
| `format_arg' attribute had not been specified, all the compiler |
| could tell in such calls to format functions would be that the |
| format string argument is not constant; this would generate a |
| warning when `-Wformat-nonliteral' is used, but the calls could |
| not be checked without the attribute. |
| |
| The parameter STRING-INDEX specifies which argument is the format |
| string argument (starting from one). Since non-static C++ methods |
| have an implicit `this' argument, the arguments of such methods |
| should be counted from two. |
| |
| The `format-arg' attribute allows you to identify your own |
| functions 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. |
| |
| For Objective-C dialects, the `format-arg' attribute may refer to |
| an `NSString' reference for compatibility with the `format' |
| attribute above. |
| |
| The target may also allow additional types in `format-arg' |
| attributes. *Note Format Checks Specific to Particular Target |
| Machines: Target Format Checks. |
| |
| `function_vector' |
| Use this attribute on the H8/300, H8/300H, and H8S to indicate |
| that the specified function should be called through the function |
| vector. Calling a function through the function vector 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, MeP, |
| MIPS, RX 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, |
| MicroBlaze, 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. |
| |
| On MIPS targets, you can use the following attributes to modify |
| the behavior of an interrupt handler: |
| `use_shadow_register_set' |
| Assume that the handler uses a shadow register set, instead of |
| the main general-purpose registers. |
| |
| `keep_interrupts_masked' |
| Keep interrupts masked for the whole function. Without this |
| attribute, GCC tries to reenable interrupts for as much of |
| the function as it can. |
| |
| `use_debug_exception_return' |
| Return using the `deret' instruction. Interrupt handlers |
| that don't have this attribute return using `eret' instead. |
| |
| You can use any combination of these attributes, as shown below: |
| void __attribute__ ((interrupt)) v0 (); |
| void __attribute__ ((interrupt, use_shadow_register_set)) v1 (); |
| void __attribute__ ((interrupt, keep_interrupts_masked)) v2 (); |
| void __attribute__ ((interrupt, use_debug_exception_return)) v3 (); |
| void __attribute__ ((interrupt, use_shadow_register_set, |
| keep_interrupts_masked)) v4 (); |
| void __attribute__ ((interrupt, use_shadow_register_set, |
| use_debug_exception_return)) v5 (); |
| void __attribute__ ((interrupt, keep_interrupts_masked, |
| use_debug_exception_return)) v6 (); |
| void __attribute__ ((interrupt, use_shadow_register_set, |
| keep_interrupts_masked, |
| use_debug_exception_return)) v7 (); |
| |
| `ifunc ("RESOLVER")' |
| The `ifunc' attribute is used to mark a function as an indirect |
| function using the STT_GNU_IFUNC symbol type extension to the ELF |
| standard. This allows the resolution of the symbol value to be |
| determined dynamically at load time, and an optimized version of |
| the routine can be selected for the particular processor or other |
| system characteristics determined then. To use this attribute, |
| first define the implementation functions available, and a |
| resolver function that returns a pointer to the selected |
| implementation function. The implementation functions' |
| declarations must match the API of the function being implemented, |
| the resolver's declaration is be a function returning pointer to |
| void function returning void: |
| |
| void *my_memcpy (void *dst, const void *src, size_t len) |
| { |
| ... |
| } |
| |
| static void (*resolve_memcpy (void)) (void) |
| { |
| return my_memcpy; // we'll just always select this routine |
| } |
| |
| The exported header file declaring the function the user calls |
| would contain: |
| |
| extern void *memcpy (void *, const void *, size_t); |
| |
| allowing the user to call this as a regular function, unaware of |
| the implementation. Finally, the indirect function needs to be |
| defined in the same translation unit as the resolver function: |
| |
| void *memcpy (void *, const void *, size_t) |
| __attribute__ ((ifunc ("resolve_memcpy"))); |
| |
| Indirect functions cannot be weak, and require a recent binutils |
| (at least version 2.20.1), and GNU C library (at least version |
| 2.11.1). |
| |
| `interrupt_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. |
| |
| `l2' |
| On the Blackfin, this attribute specifies a function to be placed |
| into L2 SRAM. The function will be put into a specific section |
| named `.l1.text'. With `-mfdpic', callers of such functions will |
| use an inlined PLT. |
| |
| `leaf' |
| Calls to external functions with this attribute must return to the |
| current compilation unit only by return or by exception handling. |
| In particular, leaf functions are not allowed to call callback |
| function passed to it from the current compilation unit or |
| directly call functions exported by the unit or longjmp into the |
| unit. Leaf function might still call functions from other |
| compilation units and thus they are not necessarily leaf in the |
| sense that they contain no function calls at all. |
| |
| The attribute is intended for library functions to improve |
| dataflow analysis. The compiler takes the hint that any data not |
| escaping the current compilation unit can not be used or modified |
| by the leaf function. For example, the `sin' function is a leaf |
| function, but `qsort' is not. |
| |
| Note that leaf functions might invoke signals and signal handlers |
| might be defined in the current compilation unit and use static |
| variables. The only compliant way to write such a signal handler |
| is to declare such variables `volatile'. |
| |
| The attribute has no effect on functions defined within the |
| current compilation unit. This is to allow easy merging of |
| multiple compilation units into one, for example, by using the |
| link time optimization. For this reason the attribute is not |
| allowed on types to annotate indirect calls. |
| |
| `long_call/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, the `ms_abi' attribute for Windows targets currently requires |
| the `-maccumulate-outgoing-args' option. |
| |
| `callee_pop_aggregate_return (NUMBER)' |
| On 32-bit i?86-*-* targets, you can control by those attribute for |
| aggregate return in memory, if the caller is responsible to pop |
| the hidden pointer together with the rest of the arguments - |
| NUMBER equal to zero -, or if the callee is responsible to pop |
| hidden pointer - NUMBER equal to one. |
| |
| For i?86-netware, the caller pops the stack for the hidden |
| arguments pointing to aggregate return value. This differs from |
| the default i386 ABI which assumes that the callee pops the stack |
| for hidden pointer. |
| |
| `ms_hook_prologue' |
| On 32 bit i[34567]86-*-* targets and 64 bit x86_64-*-* targets, |
| you can use this function attribute to make gcc generate the |
| "hot-patching" function prologue used in Win32 API functions in |
| Microsoft Windows XP Service Pack 2 and newer. |
| |
| `naked' |
| Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to |
| indicate that the specified function does not need |
| prologue/epilogue sequences generated by the compiler. It is up |
| to the programmer to provide these sequences. The only statements |
| that can be safely included in naked functions are `asm' |
| statements that do not have operands. All other statements, |
| including declarations of local variables, `if' statements, and so |
| forth, should be avoided. Naked functions should be used to |
| implement the body of an assembly function, while allowing the |
| compiler to construct the requisite function declaration for the |
| assembler. |
| |
| `near' |
| On 68HC11 and 68HC12 the `near' attribute causes the compiler to |
| use the normal calling convention based on `jsr' and `rts'. This |
| attribute can be used to cancel the effect of the `-mlong-calls' |
| option. |
| |
| On MeP targets this attribute causes the compiler to assume the |
| called function is close enough to use the normal calling |
| convention, overriding the `-mtf' command line option. |
| |
| `nesting' |
| Use this attribute together with `interrupt_handler', |
| `exception_handler' or `nmi_handler' to indicate that the function |
| entry code should enable nested interrupts or exceptions. |
| |
| `nmi_handler' |
| Use this attribute on the Blackfin to indicate that the specified |
| function is an NMI handler. The compiler 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. |
| |
| `no_split_stack' |
| If `-fsplit-stack' is given, functions will have a small prologue |
| which decides whether to split the stack. Functions with the |
| `no_split_stack' attribute will not have that prologue, and thus |
| may run with only a small amount of stack space available. |
| |
| `noinline' |
| This function attribute prevents a function from being considered |
| for inlining. If the function does not have side-effects, there |
| are optimizations other than inlining that 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. |
| |
| `noclone' |
| This function attribute prevents a function from being considered |
| for cloning - a mechanism which produces specialized copies of |
| functions and which is (currently) performed by interprocedural |
| constant propagation. |
| |
| `nonnull (ARG-INDEX, ...)' |
| The `nonnull' attribute specifies that some function parameters |
| should be non-null pointers. For instance, the declaration: |
| |
| extern void * |
| my_memcpy (void *dest, const void *src, size_t len) |
| __attribute__((nonnull (1, 2))); |
| |
| causes the compiler to check that, in calls to `my_memcpy', |
| arguments DEST and SRC are non-null. If the compiler determines |
| that a null pointer is passed in an argument slot marked as |
| non-null, and the `-Wnonnull' option is enabled, a warning is |
| issued. The compiler may also choose to make optimizations based |
| on the knowledge that certain function arguments will not be null. |
| |
| 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 ARG-INDEX. |
| |
| 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. |
| |
| `OS_main/OS_task' |
| On AVR, functions with the `OS_main' or `OS_task' attribute do not |
| save/restore any call-saved register in their prologue/epilogue. |
| |
| The `OS_main' attribute can be used when there _is guarantee_ that |
| interrupts are disabled at the time when the function is entered. |
| This will save resources when the stack pointer has to be changed |
| to set up a frame for local variables. |
| |
| The `OS_task' attribute can be used when there is _no guarantee_ |
| that interrupts are disabled at that time when the function is |
| entered like for, e.g. task functions in a multi-threading |
| operating system. In that case, changing the stack pointer |
| register will be guarded by save/clear/restore of the global |
| interrupt enable flag. |
| |
| The differences to the `naked' function attrubute are: |
| * `naked' functions do not have a return instruction whereas |
| `OS_main' and `OS_task' functions will have a `RET' or `RETI' |
| return instruction. |
| |
| * `naked' functions do not set up a frame for local variables |
| or a frame pointer whereas `OS_main' and `OS_task' do this as |
| needed. |
| |
| `pcs' |
| The `pcs' attribute can be used to control the calling convention |
| used for a function on ARM. The attribute takes an argument that |
| specifies the calling convention to use. |
| |
| When compiling using the AAPCS ABI (or a variant of that) then |
| valid values for the argument are `"aapcs"' and `"aapcs-vfp"'. In |
| order to use a variant other than `"aapcs"' then the compiler must |
| be permitted to use the appropriate co-processor registers (i.e., |
| the VFP registers must be available in order to use `"aapcs-vfp"'). |
| For example, |
| |
| /* Argument passed in r0, and result returned in r0+r1. */ |
| double f2d (float) __attribute__((pcs("aapcs"))); |
| |
| Variadic functions always use the `"aapcs"' calling convention and |
| the compiler will reject attempts to specify an alternative. |
| |
| `pure' |
| Many functions have no effects except the return value and their |
| return value depends only on the parameters and/or global |
| variables. Such a function can be subject to common subexpression |
| elimination and loop optimization just as an arithmetic operator |
| would be. These functions should be declared with the attribute |
| `pure'. For example, |
| |
| int square (int) __attribute__ ((pure)); |
| |
| says that the hypothetical function `square' is safe to call fewer |
| times than the program says. |
| |
| Some of common examples of pure functions are `strlen' or `memcmp'. |
| Interesting non-pure functions are functions with infinite loops |
| or those depending on volatile memory or other system resource, |
| that may change between two consecutive calls (such as `feof' in a |
| multithreading environment). |
| |
| The attribute `pure' is not implemented in GCC versions earlier |
| than 2.96. |
| |
| `hot' |
| The `hot' attribute 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. |
| |
| `save_volatiles' |
| Use this attribute on the MicroBlaze to indicate that the function |
| is an interrupt handler. All volatile registers (in addition to |
| non-volatile registers) will be saved in the function prologue. |
| If the function is a leaf function, only volatiles used by the |
| function are saved. A normal function return is generated instead |
| of a return from interrupt. |
| |
| `section ("SECTION-NAME")' |
| Normally, the compiler places the code it generates in the `text' |
| section. Sometimes, however, you need additional sections, or you |
| need certain particular functions to appear in special sections. |
| The `section' attribute specifies that a function lives in a |
| particular section. For example, the declaration: |
| |
| extern void foobar (void) __attribute__ ((section ("bar"))); |
| |
| puts the function `foobar' in the `bar' section. |
| |
| Some file formats do not support arbitrary sections so the |
| `section' attribute is not available on all platforms. If you |
| need to map the entire contents of a module to a particular |
| section, consider using the facilities of the linker instead. |
| |
| `sentinel' |
| This function attribute ensures that a parameter in a function |
| call is an explicit `NULL'. The attribute is only valid on |
| variadic functions. By default, the sentinel is located at |
| position zero, the last parameter of the function call. If an |
| optional integer position argument P is supplied to the attribute, |
| the sentinel must be located at position P counting backwards from |
| the end of the argument list. |
| |
| __attribute__ ((sentinel)) |
| is equivalent to |
| __attribute__ ((sentinel(0))) |
| |
| The attribute is automatically set with a position of 0 for the |
| built-in functions `execl' and `execlp'. The built-in function |
| `execle' has the attribute set with a position of 1. |
| |
| A valid `NULL' in this context is defined as zero with any pointer |
| type. If your system defines the `NULL' macro with an integer type |
| then you need to add an explicit cast. GCC replaces `stddef.h' |
| with a copy that redefines NULL appropriately. |
| |
| The warnings for missing or incorrect sentinels are enabled with |
| `-Wformat'. |
| |
| `short_call' |
| See long_call/short_call. |
| |
| `shortcall' |
| See longcall/shortcall. |
| |
| `signal' |
| Use this attribute on the AVR to indicate that the specified |
| function is 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. |
| |
| `fma4' |
| `no-fma4' |
| Enable/disable the generation of the FMA4 instructions. |
| |
| `xop' |
| `no-xop' |
| Enable/disable the generation of the XOP instructions. |
| |
| `lwp' |
| `no-lwp' |
| Enable/disable the generation of the LWP instructions. |
| |
| `ssse3' |
| `no-ssse3' |
| Enable/disable the generation of the SSSE3 instructions. |
| |
| `cld' |
| `no-cld' |
| Enable/disable the generation of the CLD before string moves. |
| |
| `fancy-math-387' |
| `no-fancy-math-387' |
| Enable/disable the generation of the `sin', `cos', and `sqrt' |
| instructions on the 387 floating point unit. |
| |
| `fused-madd' |
| `no-fused-madd' |
| Enable/disable the generation of the fused multiply/add |
| instructions. |
| |
| `ieee-fp' |
| `no-ieee-fp' |
| Enable/disable the generation of floating point that depends |
| on IEEE arithmetic. |
| |
| `inline-all-stringops' |
| `no-inline-all-stringops' |
| Enable/disable inlining of string operations. |
| |
| `inline-stringops-dynamically' |
| `no-inline-stringops-dynamically' |
| Enable/disable the generation of the inline code to do small |
| string operations and calling the library routines for large |
| operations. |
| |
| `align-stringops' |
| `no-align-stringops' |
| Do/do not align destination of inlined string operations. |
| |
| `recip' |
| `no-recip' |
| Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and |
| RSQRTPS instructions followed an additional Newton-Raphson |
| step instead of doing a floating point division. |
| |
| `arch=ARCH' |
| Specify the architecture to generate code for in compiling |
| the function. |
| |
| `tune=TUNE' |
| Specify the architecture to tune for in compiling the |
| function. |
| |
| `fpmath=FPMATH' |
| Specify which floating point unit to use. The |
| `target("fpmath=sse,387")' option must be specified as |
| `target("fpmath=sse+387")' because the comma would separate |
| different options. |
| |
| On the PowerPC, the following options are allowed: |
| |
| `altivec' |
| `no-altivec' |
| Generate code that uses (does not use) AltiVec instructions. |
| In 32-bit code, you cannot enable Altivec instructions unless |
| `-mabi=altivec' was used on the command line. |
| |
| `cmpb' |
| `no-cmpb' |
| Generate code that uses (does not use) the compare bytes |
| instruction implemented on the POWER6 processor and other |
| processors that support the PowerPC V2.05 architecture. |
| |
| `dlmzb' |
| `no-dlmzb' |
| Generate code that uses (does not use) the string-search |
| `dlmzb' instruction on the IBM 405, 440, 464 and 476 |
| processors. This instruction is generated by default when |
| targetting those processors. |
| |
| `fprnd' |
| `no-fprnd' |
| Generate code that uses (does not use) the FP round to integer |
| instructions implemented on the POWER5+ processor and other |
| processors that support the PowerPC V2.03 architecture. |
| |
| `hard-dfp' |
| `no-hard-dfp' |
| Generate code that uses (does not use) the decimal floating |
| point instructions implemented on some POWER processors. |
| |
| `isel' |
| `no-isel' |
| Generate code that uses (does not use) ISEL instruction. |
| |
| `mfcrf' |
| `no-mfcrf' |
| Generate code that uses (does not use) the move from condition |
| register field instruction implemented on the POWER4 |
| processor and other processors that support the PowerPC V2.01 |
| architecture. |
| |
| `mfpgpr' |
| `no-mfpgpr' |
| Generate code that uses (does not use) the FP move to/from |
| general purpose register instructions implemented on the |
| POWER6X processor and other processors that support the |
| extended PowerPC V2.05 architecture. |
| |
| `mulhw' |
| `no-mulhw' |
| Generate code that uses (does not use) the half-word multiply |
| and multiply-accumulate instructions on the IBM 405, 440, 464 |
| and 476 processors. These instructions are generated by |
| default when targetting those processors. |
| |
| `multiple' |
| `no-multiple' |
| Generate code that uses (does not use) the load multiple word |
| instructions and the store multiple word instructions. |
| |
| `update' |
| `no-update' |
| Generate code that uses (does not use) the load or store |
| instructions that update the base register to the address of |
| the calculated memory location. |
| |
| `popcntb' |
| `no-popcntb' |
| Generate code that uses (does not use) the popcount and double |
| precision FP reciprocal estimate instruction implemented on |
| the POWER5 processor and other processors that support the |
| PowerPC V2.02 architecture. |
| |
| `popcntd' |
| `no-popcntd' |
| Generate code that uses (does not use) the popcount |
| instruction implemented on the POWER7 processor and other |
| processors that support the PowerPC V2.06 architecture. |
| |
| `powerpc-gfxopt' |
| `no-powerpc-gfxopt' |
| Generate code that uses (does not use) the optional PowerPC |
| architecture instructions in the Graphics group, including |
| floating-point select. |
| |
| `powerpc-gpopt' |
| `no-powerpc-gpopt' |
| Generate code that uses (does not use) the optional PowerPC |
| architecture instructions in the General Purpose group, |
| including floating-point square root. |
| |
| `recip-precision' |
| `no-recip-precision' |
| Assume (do not assume) that the reciprocal estimate |
| instructions provide higher precision estimates than is |
| mandated by the powerpc ABI. |
| |
| `string' |
| `no-string' |
| Generate code that uses (does not use) the load string |
| instructions and the store string word instructions to save |
| multiple registers and do small block moves. |
| |
| `vsx' |
| `no-vsx' |
| Generate code that uses (does not use) vector/scalar (VSX) |
| instructions, and also enable the use of built-in functions |
| that allow more direct access to the VSX instruction set. In |
| 32-bit code, you cannot enable VSX or Altivec instructions |
| unless `-mabi=altivec' was used on the command line. |
| |
| `friz' |
| `no-friz' |
| Generate (do not generate) the `friz' instruction when the |
| `-funsafe-math-optimizations' option is used to optimize |
| rounding a floating point value to 64-bit integer and back to |
| floating point. The `friz' instruction does not return the |
| same value if the floating point number is too large to fit |
| in an integer. |
| |
| `avoid-indexed-addresses' |
| `no-avoid-indexed-addresses' |
| Generate code that tries to avoid (not avoid) the use of |
| indexed load or store instructions. |
| |
| `paired' |
| `no-paired' |
| Generate code that uses (does not use) the generation of |
| PAIRED simd instructions. |
| |
| `longcall' |
| `no-longcall' |
| Generate code that assumes (does not assume) that all calls |
| are far away so that a longer more expensive calling sequence |
| is required. |
| |
| `cpu=CPU' |
| Specify the architecture to generate code for when compiling |
| the function. If you select the `"target("cpu=power7)"' |
| attribute when generating 32-bit code, VSX and Altivec |
| instructions are not generated unless you use the |
| `-mabi=altivec' option on the command line. |
| |
| `tune=TUNE' |
| Specify the architecture to tune for when compiling the |
| function. If you do not specify the `target("tune=TUNE")' |
| attribute and you do specify the `target("cpu=CPU")' |
| attribute, compilation will tune for the CPU architecture, |
| and not the default tuning specified on the command line. |
| |
| On the 386/x86_64 and PowerPC backends, you can use either multiple |
| strings to specify multiple options, or you can separate the option |
| with a comma (`,'). |
| |
| On the 386/x86_64 and PowerPC backends, 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("sse3")' |
| can inline a function with `target("sse2")', since `-msse3' |
| implies `-msse2'. |
| |
| The `target' attribute is not implemented in GCC versions earlier |
| than 4.4 for the i386/x86_64 and 4.6 for the PowerPC backends. It |
| is not currently implemented for other backends. |
| |
| `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. |
| |
| `vliw' |
| On MeP, the `vliw' attribute tells the compiler to emit |
| instructions in VLIW mode instead of core mode. Note that this |
| attribute is not allowed unless a VLIW coprocessor has been |
| configured and enabled through command line options. |
| |
| `warn_unused_result' |
| The `warn_unused_result' attribute causes a warning to be emitted |
| if a caller of the function with this attribute does not use its |
| return value. This is useful for functions where not checking the |
| result is either a security problem or always a bug, such as |
| `realloc'. |
| |
| int fn () __attribute__ ((warn_unused_result)); |
| int foo () |
| { |
| if (fn () < 0) return -1; |
| fn (); |
| return 0; |
| } |
| |
| results in warning on line 5. |
| |
| `weak' |
| The `weak' attribute causes the declaration to be emitted as a weak |
| symbol rather than a global. This is primarily useful in defining |
| library functions 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 it 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. |
| |
| |
| File: gcc.info, Node: Attribute Syntax, Next: Function Prototypes, Prev: Function Attributes, Up: C Extensions |
| |
| 6.31 Attribute Syntax |
| ===================== |
| |
| This section describes the syntax with which `__attribute__' may be |
| used, and the constructs to which attribute specifiers bind, for the C |
| language. Some details may vary for C++ and Objective-C. Because of |
| infelicities in the grammar for attributes, some forms described here |
| may not be successfully parsed in all cases. |
| |
| There are some problems with the semantics of attributes in C++. For |
| example, there are no manglings for attributes, although they may affect |
| code generation, so problems may arise when attributed types are used in |
| conjunction with templates or overloading. Similarly, `typeid' does |
| not distinguish between types with different attributes. Support for |
| attributes in C++ may be restricted in future to attributes on |
| declarations only, but not on nested declarators. |
| |
| *Note Function Attributes::, for details of the semantics of attributes |
| applying to functions. *Note Variable Attributes::, for details of the |
| semantics of attributes applying to variables. *Note Type Attributes::, |
| for details of the semantics of attributes applying to structure, union |
| and enumerated types. |
| |
| An "attribute specifier" is of the form `__attribute__ |
| ((ATTRIBUTE-LIST))'. An "attribute list" is a possibly empty |
| comma-separated sequence of "attributes", where each attribute is one |
| of the following: |
| |
| * Empty. Empty attributes are ignored. |
| |
| * A word (which may be an identifier such as `unused', or a reserved |
| word such as `const'). |
| |
| * A word, followed by, in parentheses, parameters for the attribute. |
| These parameters take one of the following forms: |
| |
| * An identifier. For example, `mode' attributes use this form. |
| |
| * An identifier followed by a comma and a non-empty |
| comma-separated list of expressions. For example, `format' |
| attributes use this form. |
| |
| * A possibly empty comma-separated list of expressions. For |
| example, `format_arg' attributes use this form with the list |
| being a single integer constant expression, and `alias' |
| attributes use this form with the list being a single string |
| constant. |
| |
| An "attribute specifier list" is a sequence of one or more attribute |
| specifiers, not separated by any other tokens. |
| |
| In GNU C, an attribute specifier list may appear after the colon |
| following a label, other than a `case' or `default' label. The only |
| attribute it makes sense to use after a label is `unused'. This |
| feature is intended for 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++ only permits |
| attributes on labels if the attribute specifier is immediately followed |
| by a semicolon (i.e., the label applies to an empty statement). If the |
| semicolon is missing, C++ label attributes are ambiguous, as it is |
| permissible for a declaration, which could begin with an attribute |
| list, to be labelled in C++. Declarations cannot be labelled in C90 or |
| C99, so the ambiguity does not arise there. |
| |
| An attribute specifier list may appear as part of a `struct', `union' |
| or `enum' specifier. It may go either immediately after the `struct', |
| `union' or `enum' keyword, or after the closing brace. The former |
| syntax is preferred. Where attribute specifiers follow the closing |
| brace, they are considered to relate to the structure, union or |
| enumerated type defined, not to any enclosing declaration the type |
| specifier appears in, and the type defined is not complete until after |
| the attribute specifiers. |
| |
| Otherwise, an attribute specifier appears as part of a declaration, |
| counting declarations of unnamed parameters and type names, and relates |
| to that declaration (which may be nested in another declaration, for |
| example in the case of a parameter declaration), or to a particular |
| declarator within a declaration. Where an attribute specifier is |
| applied to a parameter declared as a function or an array, it should |
| apply to the function or array rather than the pointer to which the |
| parameter is implicitly converted, but this is not yet correctly |
| implemented. |
| |
| Any list of specifiers and qualifiers at the start of a declaration may |
| contain attribute specifiers, whether or not such a list may in that |
| context contain storage class specifiers. (Some attributes, however, |
| are essentially in the nature of storage class specifiers, and only make |
| sense where storage class specifiers may be used; for example, |
| `section'.) There is one necessary limitation to this syntax: the |
| first old-style parameter declaration in a function definition cannot |
| begin with an attribute specifier, because such an attribute applies to |
| the function instead by syntax described below (which, however, is not |
| yet implemented in this case). In some other cases, attribute |
| specifiers are permitted by this grammar but not yet supported by the |
| compiler. All attribute specifiers in this place relate to the |
| declaration as a whole. In the obsolescent usage where a type of `int' |
| is implied by the absence of type specifiers, such a list of specifiers |
| and qualifiers may be an attribute specifier list with no other |
| specifiers or qualifiers. |
| |
| At present, the first parameter in a function prototype must have some |
| type specifier 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 pointer to TYPE" for IDENT. |
| |
| For example, |
| |
| void (__attribute__((noreturn)) ****f) (void); |
| |
| specifies the type "pointer to pointer to pointer to pointer to |
| non-returning function returning `void'". As another example, |
| |
| char *__attribute__((aligned(8))) *f; |
| |
| specifies the type "pointer to 8-byte-aligned pointer to `char'". Note |
| again that this does not work with most attributes; for example, the |
| usage of `aligned' and `noreturn' attributes given above is not yet |
| supported. |
| |
| For compatibility with existing code written for compiler versions that |
| did not implement attributes on nested declarators, some laxity is |
| allowed in the placing of attributes. If an attribute that only applies |
| to types is applied to a declaration, it 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. |
| |
| |
| File: gcc.info, Node: Function Prototypes, Next: C++ Comments, Prev: Attribute Syntax, Up: C Extensions |
| |
| 6.32 Prototypes and Old-Style Function Definitions |
| ================================================== |
| |
| GNU C extends ISO C to allow a function prototype to override a later |
| old-style non-prototype definition. Consider the following example: |
| |
| /* Use prototypes unless the compiler is old-fashioned. */ |
| #ifdef __STDC__ |
| #define P(x) x |
| #else |
| #define P(x) () |
| #endif |
| |
| /* Prototype function declaration. */ |
| int isroot P((uid_t)); |
| |
| /* Old-style function definition. */ |
| int |
| isroot (x) /* ??? lossage here ??? */ |
| uid_t x; |
| { |
| return x == 0; |
| } |
| |
| Suppose the type `uid_t' happens to be `short'. ISO C does not allow |
| this example, because subword arguments in old-style non-prototype |
| definitions are promoted. Therefore in this example the function |
| definition's argument is really an `int', which does not match the |
| prototype argument type of `short'. |
| |
| This restriction of ISO C makes it hard to write code that is portable |
| to traditional C compilers, because the programmer does not know |
| whether the `uid_t' type is `short', `int', or `long'. Therefore, in |
| cases like these GNU C allows a prototype to override a later old-style |
| definition. More precisely, in GNU C, a function prototype argument |
| type overrides the argument type specified by a later old-style |
| definition if the former type is the same as the latter type before |
| promotion. Thus in GNU C the above example is equivalent to the |
| following: |
| |
| int isroot (uid_t); |
| |
| int |
| isroot (uid_t x) |
| { |
| return x == 0; |
| } |
| |
| GNU C++ does not support old-style function definitions, so this |
| extension is irrelevant. |
| |
| |
| File: gcc.info, Node: C++ Comments, Next: Dollar Signs, Prev: Function Prototypes, Up: C Extensions |
| |
| 6.33 C++ Style Comments |
| ======================= |
| |
| In GNU C, you may use C++ style comments, which start with `//' and |
| continue until the end of the line. Many other C implementations allow |
| such comments, and they are included in the 1999 C standard. However, |
| C++ style comments are not recognized if you specify an `-std' option |
| specifying a version of ISO C before C99, or `-ansi' (equivalent to |
| `-std=c90'). |
| |
| |
| File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: C++ Comments, Up: C Extensions |
| |
| 6.34 Dollar Signs in Identifier Names |
| ===================================== |
| |
| In GNU C, you may normally use dollar signs in identifier names. This |
| is because many traditional C implementations allow such identifiers. |
| However, dollar signs in identifiers are not supported on a few target |
| machines, typically because the target assembler does not allow them. |
| |
| |
| File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: C Extensions |
| |
| 6.35 The Character <ESC> in Constants |
| ===================================== |
| |
| You can use the sequence `\e' in a string or character constant to |
| stand for the ASCII character <ESC>. |
| |
| |
| File: gcc.info, Node: Variable Attributes, Next: Type Attributes, Prev: Character Escapes, Up: C Extensions |
| |
| 6.36 Specifying Attributes of Variables |
| ======================================= |
| |
| The keyword `__attribute__' allows you to specify special attributes of |
| variables or structure fields. This keyword is followed by an |
| attribute specification inside double parentheses. Some attributes are |
| currently defined generically for variables. Other attributes are |
| defined for variables on particular target systems. Other attributes |
| are available for functions (*note Function Attributes::) and for types |
| (*note Type Attributes::). Other front ends might define more |
| attributes (*note Extensions to the C++ Language: C++ Extensions.). |
| |
| You may also specify attributes with `__' preceding and following each |
| keyword. This allows you to use them in header files without being |
| concerned about a possible macro of the same name. For example, you |
| may use `__aligned__' instead of `aligned'. |
| |
| *Note Attribute Syntax::, for details of the exact syntax for using |
| attributes. |
| |
| `aligned (ALIGNMENT)' |
| This attribute specifies a minimum alignment for the variable or |
| structure field, measured in bytes. For example, the declaration: |
| |
| int x __attribute__ ((aligned (16))) = 0; |
| |
| causes the compiler to allocate the global variable `x' on a |
| 16-byte boundary. On a 68040, this could be used in conjunction |
| with an `asm' expression to access the `move16' instruction which |
| requires 16-byte aligned operands. |
| |
| You can also specify the alignment of structure fields. For |
| example, to create a double-word aligned `int' pair, you could |
| write: |
| |
| struct foo { int x[2] __attribute__ ((aligned (8))); }; |
| |
| This is an alternative to creating a union with a `double' member |
| 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' |
| `deprecated (MSG)' |
| The `deprecated' attribute results in a warning if the variable is |
| used anywhere in the source file. This is useful when identifying |
| variables that are expected to be removed in a future version of a |
| program. The warning also includes the location of the declaration |
| of the deprecated variable, to enable users to easily find further |
| information about why the variable is deprecated, or what they |
| should do instead. Note that the warning only occurs for uses: |
| |
| extern int old_var __attribute__ ((deprecated)); |
| extern int old_var; |
| int new_fn () { return old_var; } |
| |
| results in a warning on line 3 but not line 2. The optional msg |
| argument, which must be a string, will be printed in the warning if |
| present. |
| |
| The `deprecated' attribute can also be used for functions and |
| types (*note Function Attributes::, *note Type Attributes::.) |
| |
| `mode (MODE)' |
| This attribute specifies the data type for the |
| declaration--whichever type corresponds to the mode MODE. This in |
| effect lets you request an integer or floating point type |
| according to its width. |
| |
| You may also specify a mode of `byte' or `__byte__' to indicate |
| the mode corresponding to a one-byte integer, `word' or `__word__' |
| for the mode of a one-word integer, and `pointer' or `__pointer__' |
| for the mode used to represent pointers. |
| |
| `packed' |
| The `packed' attribute specifies that a variable or structure field |
| should have the smallest possible alignment--one byte for a |
| variable, and one bit for a field, unless you specify a larger |
| value with the `aligned' attribute. |
| |
| Here is a structure in which the field `x' is packed, so that it |
| immediately follows `a': |
| |
| struct foo |
| { |
| char a; |
| int x[2] __attribute__ ((packed)); |
| }; |
| |
| _Note:_ The 4.1, 4.2 and 4.3 series of GCC ignore the `packed' |
| attribute on bit-fields of type `char'. This has been fixed in |
| GCC 4.4 but the change can lead to differences in the structure |
| layout. See the documentation of `-Wpacked-bitfield-compat' for |
| more information. |
| |
| `section ("SECTION-NAME")' |
| Normally, the compiler places the objects it generates in sections |
| like `data' and `bss'. Sometimes, however, you need additional |
| sections, or you need certain particular variables to appear in |
| special sections, for example to map to special hardware. The |
| `section' attribute specifies that a variable (or function) lives |
| in a particular section. For example, this small program uses |
| several specific section names: |
| |
| struct duart a __attribute__ ((section ("DUART_A"))) = { 0 }; |
| struct duart b __attribute__ ((section ("DUART_B"))) = { 0 }; |
| char stack[10000] __attribute__ ((section ("STACK"))) = { 0 }; |
| int init_data __attribute__ ((section ("INITDATA"))); |
| |
| main() |
| { |
| /* Initialize stack pointer */ |
| init_sp (stack + sizeof (stack)); |
| |
| /* Initialize initialized data */ |
| memcpy (&init_data, &data, &edata - &data); |
| |
| /* Turn on the serial ports */ |
| init_duart (&a); |
| init_duart (&b); |
| } |
| |
| Use the `section' attribute with _global_ variables and not |
| _local_ variables, as shown in the example. |
| |
| You may use the `section' attribute with initialized or |
| uninitialized global variables but the linker requires each object |
| be defined once, with the exception that uninitialized variables |
| tentatively go in the `common' (or `bss') section and can be |
| multiply "defined". Using the `section' attribute 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::. |
| |
| |
| 6.36.1 AVR Variable Attributes |
| ------------------------------ |
| |
| `progmem' |
| The `progmem' attribute is used on the AVR to place data in the |
| program memory address space (flash). This is accomplished by |
| putting respective variables into a section whose name starts with |
| `.progmem'. |
| |
| AVR is a Harvard architecture processor and data and reas only data |
| normally resides in the data memory address space (RAM). |
| |
| 6.36.2 Blackfin Variable Attributes |
| ----------------------------------- |
| |
| Three attributes are currently defined for the Blackfin. |
| |
| `l1_data' |
| `l1_data_A' |
| `l1_data_B' |
| Use these attributes on the Blackfin to place the variable into L1 |
| Data SRAM. Variables with `l1_data' attribute 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'. |
| |
| `l2' |
| Use this attribute on the Blackfin to place the variable into L2 |
| SRAM. Variables with `l2' attribute will be put into the specific |
| section named `.l2.data'. |
| |
| 6.36.3 M32R/D Variable Attributes |
| --------------------------------- |
| |
| One attribute is currently defined for the M32R/D. |
| |
| `model (MODEL-NAME)' |
| Use this attribute on the M32R/D to set the addressability of an |
| object. The identifier MODEL-NAME is one of `small', `medium', or |
| `large', representing each of the code models. |
| |
| Small model objects live in the lower 16MB of memory (so that their |
| addresses can be loaded with the `ld24' instruction). |
| |
| Medium and large model objects may live anywhere in the 32-bit |
| address space (the compiler will generate `seth/add3' instructions |
| to load their addresses). |
| |
| 6.36.4 MeP Variable Attributes |
| ------------------------------ |
| |
| The MeP target has a number of addressing modes and busses. The `near' |
| space spans the standard memory space's first 16 megabytes (24 bits). |
| The `far' space spans the entire 32-bit memory space. The `based' |
| space is a 128 byte region in the memory space which is addressed |
| relative to the `$tp' register. The `tiny' space is a 65536 byte |
| region relative to the `$gp' register. In addition to these memory |
| regions, the MeP target has a separate 16-bit control bus which is |
| specified with `cb' attributes. |
| |
| `based' |
| Any variable with the `based' attribute will be assigned to the |
| `.based' section, and will be accessed with relative to the `$tp' |
| register. |
| |
| `tiny' |
| Likewise, the `tiny' attribute assigned variables to the `.tiny' |
| section, relative to the `$gp' register. |
| |
| `near' |
| Variables with the `near' attribute are assumed to have addresses |
| that fit in a 24-bit addressing mode. This is the default for |
| large variables (`-mtiny=4' is the default) but this attribute can |
| override `-mtiny=' for small variables, or override `-ml'. |
| |
| `far' |
| Variables with the `far' attribute are addressed using a full |
| 32-bit address. Since this covers the entire memory space, this |
| allows modules to make no assumptions about where variables might |
| be stored. |
| |
| `io' |
| `io (ADDR)' |
| Variables with the `io' attribute are used to address |
| memory-mapped peripherals. If an address is specified, the |
| variable is assigned that address, else it is not assigned an |
| address (it is assumed some other module will assign an address). |
| Example: |
| |
| int timer_count __attribute__((io(0x123))); |
| |
| `cb' |
| `cb (ADDR)' |
| Variables with the `cb' attribute are used to access the control |
| bus, using special instructions. `addr' indicates the control bus |
| address. Example: |
| |
| int cpu_clock __attribute__((cb(0x123))); |
| |
| |
| 6.36.5 i386 Variable Attributes |
| ------------------------------- |
| |
| Two attributes are currently defined for i386 configurations: |
| `ms_struct' and `gcc_struct' |
| |
| `ms_struct' |
| `gcc_struct' |
| If `packed' is used on a structure, or if bit-fields are used it |
| may be that the Microsoft ABI 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. |
| |
| 6.36.6 PowerPC Variable Attributes |
| ---------------------------------- |
| |
| Three attributes currently are defined for PowerPC configurations: |
| `altivec', `ms_struct' and `gcc_struct'. |
| |
| For full documentation of the struct attributes please see the |
| documentation in *note i386 Variable Attributes::. |
| |
| For documentation of `altivec' attribute please see the documentation |
| in *note PowerPC Type Attributes::. |
| |
| 6.36.7 SPU Variable Attributes |
| ------------------------------ |
| |
| The SPU supports the `spu_vector' attribute for variables. For |
| documentation of this attribute please see the documentation in *note |
| SPU Type Attributes::. |
| |
| 6.36.8 Xstormy16 Variable Attributes |
| ------------------------------------ |
| |
| One attribute is currently defined for xstormy16 configurations: |
| `below100'. |
| |
| `below100' |
| If a variable has the `below100' attribute (`BELOW100' is allowed |
| also), GCC 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. |
| |
| |
| |
| File: gcc.info, Node: Type Attributes, Next: Alignment, Prev: Variable Attributes, Up: C Extensions |
| |
| 6.37 Specifying Attributes of Types |
| =================================== |
| |
| The keyword `__attribute__' allows you to specify special attributes of |
| `struct' and `union' types when you define such types. This keyword is |
| followed by an attribute specification inside double parentheses. |
| Seven attributes are currently defined for types: `aligned', `packed', |
| `transparent_union', `unused', `deprecated', `visibility', and |
| `may_alias'. Other attributes are defined for functions (*note |
| Function Attributes::) and for variables (*note Variable Attributes::). |
| |
| You may also specify any one of these attributes with `__' preceding |
| and following its keyword. This allows you to use these attributes in |
| header files without being concerned about a possible macro of the same |
| name. For example, you may use `__aligned__' instead of `aligned'. |
| |
| You may specify type attributes in an enum, struct or union type |
| declaration or definition, or for other types in a `typedef' |
| declaration. |
| |
| For an enum, struct or union type, you may specify attributes either |
| between the enum, struct or union tag and the name of the type, or just |
| past the closing curly brace of the _definition_. The former syntax is |
| preferred. |
| |
| *Note Attribute Syntax::, for details of the exact syntax for using |
| attributes. |
| |
| `aligned (ALIGNMENT)' |
| This attribute specifies a minimum alignment (in bytes) for |
| variables of the specified type. For example, the declarations: |
| |
| struct S { short f[3]; } __attribute__ ((aligned (8))); |
| typedef int more_aligned_int __attribute__ ((aligned (8))); |
| |
| force the compiler to 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 an `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' |
| `deprecated (MSG)' |
| The `deprecated' attribute results in a warning if the type is |
| used anywhere in the source file. This is useful when identifying |
| types that are expected to be removed in a future version of a |
| program. If possible, the warning also includes the location of |
| the declaration of the deprecated type, to enable users to easily |
| find further information about why the type is deprecated, or what |
| they should do instead. Note that the warnings only occur for |
| uses and then only if the type is being applied to an identifier |
| that itself is not being declared as deprecated. |
| |
| typedef int T1 __attribute__ ((deprecated)); |
| T1 x; |
| typedef T1 T2; |
| T2 y; |
| typedef T1 T3 __attribute__ ((deprecated)); |
| T3 z __attribute__ ((deprecated)); |
| |
| results in a warning on line 2 and 3 but not lines 4, 5, or 6. No |
| warning is issued for line 4 because T2 is not explicitly |
| deprecated. Line 5 has no warning because T3 is explicitly |
| deprecated. Similarly for line 6. The optional msg argument, |
| which must be a string, will be printed in the warning if present. |
| |
| The `deprecated' attribute can also be used for functions and |
| variables (*note Function Attributes::, *note Variable |
| Attributes::.) |
| |
| `may_alias' |
| Accesses through pointers to types with this attribute are not |
| subject to type-based alias analysis, but are instead assumed to |
| be able to alias any other type of objects. In the context of |
| 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. |
| |
| |
| 6.37.1 ARM Type Attributes |
| -------------------------- |
| |
| On those ARM targets that support `dllimport' (such as Symbian OS), you |
| can use the `notshared' attribute to indicate that the virtual table |
| and other similar data for a class should not be exported from a DLL. |
| For example: |
| |
| class __declspec(notshared) C { |
| public: |
| __declspec(dllimport) C(); |
| virtual void f(); |
| } |
| |
| __declspec(dllexport) |
| C::C() {} |
| |
| In this code, `C::C' is exported from the current DLL, but the virtual |
| table for `C' is not exported. (You can use `__attribute__' instead of |
| `__declspec' if you prefer, but most Symbian OS code uses `__declspec'.) |
| |
| 6.37.2 MeP Type Attributes |
| -------------------------- |
| |
| Many of the MeP variable attributes may be applied to types as well. |
| Specifically, the `based', `tiny', `near', and `far' attributes may be |
| applied to either. The `io' and `cb' attributes may not be applied to |
| types. |
| |
| 6.37.3 i386 Type Attributes |
| --------------------------- |
| |
| Two attributes are currently defined for i386 configurations: |
| `ms_struct' and `gcc_struct'. |
| |
| `ms_struct' |
| `gcc_struct' |
| If `packed' is used on a structure, or if bit-fields are used it |
| may be that the Microsoft ABI packs them differently than GCC |
| 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))'. |
| |
| 6.37.4 PowerPC Type Attributes |
| ------------------------------ |
| |
| Three attributes currently are defined for PowerPC configurations: |
| `altivec', `ms_struct' and `gcc_struct'. |
| |
| For full documentation of the `ms_struct' and `gcc_struct' attributes |
| please see the documentation in *note i386 Type Attributes::. |
| |
| The `altivec' attribute allows one to declare AltiVec vector data |
| types supported by the AltiVec Programming Interface Manual. The |
| attribute requires an argument to specify one of three vector types: |
| `vector__', `pixel__' (always followed by unsigned short), and `bool__' |
| (always followed by unsigned). |
| |
| __attribute__((altivec(vector__))) |
| __attribute__((altivec(pixel__))) unsigned short |
| __attribute__((altivec(bool__))) unsigned |
| |
| These attributes mainly are intended to support the `__vector', |
| `__pixel', and `__bool' AltiVec keywords. |
| |
| 6.37.5 SPU Type Attributes |
| -------------------------- |
| |
| The SPU supports the `spu_vector' attribute for types. This attribute |
| allows one to declare vector data types supported by the |
| Sony/Toshiba/IBM SPU Language Extensions Specification. It is intended |
| to support the `__vector' keyword. |
| |
| |
| File: gcc.info, Node: Alignment, Next: Inline, Prev: Type Attributes, Up: C Extensions |
| |
| 6.38 Inquiring on Alignment of Types or Variables |
| ================================================= |
| |
| The keyword `__alignof__' allows you to inquire about how an object is |
| aligned, or the minimum alignment usually required by a type. Its |
| syntax is just like `sizeof'. |
| |
| For example, if the target machine requires a `double' value to be |
| aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This |
| is true on many RISC machines. On more traditional machine designs, |
| `__alignof__ (double)' is 4 or even 2. |
| |
| Some machines never actually require alignment; they allow reference |
| to any data type even at an odd address. For these machines, |
| `__alignof__' reports the smallest alignment that GCC 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. |
| |
| |
| File: gcc.info, Node: Inline, Next: Volatiles, Prev: Alignment, Up: C Extensions |
| |
| 6.39 An Inline Function is As Fast As a Macro |
| ============================================= |
| |
| By declaring a function inline, you can direct GCC to make calls to |
| that function faster. One way GCC can achieve this is to integrate |
| that function's code into the code for its callers. This makes |
| execution faster by eliminating the function-call overhead; in |
| addition, if any of the actual argument values are constant, their |
| known values may permit simplifications at compile time so that not all |
| of the inline function's code needs to be included. The effect on code |
| size is less predictable; object code may be larger or smaller with |
| function inlining, depending on the particular case. You can also |
| direct GCC to try to integrate all "simple enough" functions into their |
| callers with the option `-finline-functions'. |
| |
| GCC implements three different semantics of declaring a function |
| inline. One is available with `-std=gnu89' or `-fgnu89-inline' or when |
| `gnu_inline' attribute is present on all inline declarations, another |
| when `-std=c99', `-std=c1x', `-std=gnu99' or `-std=gnu1x' (without |
| `-fgnu89-inline'), and the third is used when compiling C++. |
| |
| To declare a function inline, use the `inline' keyword in its |
| declaration, like this: |
| |
| static inline int |
| inc (int *a) |
| { |
| return (*a)++; |
| } |
| |
| If you are writing a header file to be included in ISO C90 programs, |
| write `__inline__' instead of `inline'. *Note Alternate Keywords::. |
| |
| The three types of inlining behave similarly in two important cases: |
| when the `inline' keyword is used on a `static' function, like the |
| example above, and when a function is first declared without using the |
| `inline' keyword and then is defined with `inline', like this: |
| |
| extern int inc (int *a); |
| inline int |
| inc (int *a) |
| { |
| return (*a)++; |
| } |
| |
| In both of these common cases, the program behaves the same as if you |
| had not used the `inline' keyword, except for its speed. |
| |
| When a function is both inline and `static', if all calls to the |
| function are integrated into the caller, and the function's address is |
| never used, then the function's own assembler code is never referenced. |
| In this case, GCC does not actually output assembler code for the |
| function, unless you specify the option `-fkeep-inline-functions'. |
| Some calls cannot be integrated for various reasons (in particular, |
| calls that precede the function's definition cannot be integrated, and |
| neither can recursive calls within the definition). If there is a |
| nonintegrated call, then the function is compiled to assembler code as |
| usual. The function must also be compiled as usual if the program |
| refers to its address, because that can't be inlined. |
| |
| Note that certain usages in a function definition can make it |
| unsuitable for inline substitution. Among these usages are: 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 C90 inlining. |
| |
| When an inline function is not `static', then the compiler must assume |
| that there may be calls from other source files; since a global symbol |
| can be defined only once in any program, the function must not be |
| defined in the other source files, so the calls therein cannot be |
| integrated. Therefore, a non-`static' inline function is always |
| compiled on its own in the usual fashion. |
| |
| If you specify both `inline' and `extern' in the function definition, |
| then the definition is used only for inlining. In no case is the |
| function compiled on its own, not even if you refer to its address |
| explicitly. Such an address becomes an external reference, as if you |
| had only declared the function, and had not defined it. |
| |
| This combination of `inline' and `extern' has almost the effect of a |
| macro. The way to use it is to put a function definition in a header |
| file with these keywords, and put another copy of the definition |
| (lacking `inline' and `extern') in a library file. The definition in |
| the header file 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. |
| |
| |
| File: gcc.info, Node: Volatiles, Next: Extended Asm, Prev: Inline, Up: C Extensions |
| |
| 6.40 When is a Volatile Object Accessed? |
| ======================================== |
| |
| C has the concept of volatile objects. These are normally accessed by |
| pointers and used for accessing hardware or inter-thread communication. |
| The standard encourages compilers to refrain from optimizations |
| concerning accesses to volatile objects, but leaves it implementation |
| defined as to what constitutes a volatile access. The minimum |
| requirement is that at a sequence point all previous accesses to |
| volatile objects have stabilized and no subsequent accesses have |
| occurred. Thus an implementation is free to reorder and combine |
| volatile accesses which occur between sequence points, but cannot do so |
| for accesses across a sequence point. The use of volatile does not |
| allow you to violate the restriction on updating objects multiple times |
| between two sequence points. |
| |
| Accesses to non-volatile objects are not ordered with respect to |
| volatile accesses. You cannot use a volatile object as a memory |
| barrier to order a sequence of writes to non-volatile memory. For |
| instance: |
| |
| int *ptr = SOMETHING; |
| volatile int vobj; |
| *ptr = SOMETHING; |
| vobj = 1; |
| |
| Unless *PTR and VOBJ can be aliased, it is not guaranteed that the |
| write to *PTR will have occurred by the time the update of VOBJ has |
| happened. If you need this guarantee, you must use a stronger memory |
| barrier such as: |
| |
| int *ptr = SOMETHING; |
| volatile int vobj; |
| *ptr = SOMETHING; |
| asm volatile ("" : : : "memory"); |
| vobj = 1; |
| |
| A scalar volatile object is read when it is accessed in a void context: |
| |
| volatile int *src = SOMEVALUE; |
| *src; |
| |
| Such expressions are rvalues, and GCC implements this as a read of the |
| volatile object being pointed to. |
| |
| Assignments are also expressions and have an rvalue. However when |
| assigning to a scalar volatile, the volatile object is not reread, |
| regardless of whether the assignment expression's rvalue is used or |
| not. If the assignment's rvalue is used, the value is that assigned to |
| the volatile object. For instance, there is no read of VOBJ in all the |
| following cases: |
| |
| int obj; |
| volatile int vobj; |
| vobj = SOMETHING; |
| obj = vobj = SOMETHING; |
| obj ? vobj = ONETHING : vobj = ANOTHERTHING; |
| obj = (SOMETHING, vobj = ANOTHERTHING); |
| |
| If you need to read the volatile object after an assignment has |
| occurred, you must use a separate expression with an intervening |
| sequence point. |
| |
| As bitfields are not individually addressable, volatile bitfields may |
| be implicitly read when written to, or when adjacent bitfields are |
| accessed. Bitfield operations may be optimized such that adjacent |
| bitfields are only partially accessed, if they straddle a storage unit |
| boundary. For these reasons it is unwise to use volatile bitfields to |
| access hardware. |
| |
| |
| File: gcc.info, Node: Extended Asm, Next: Constraints, Prev: Volatiles, Up: C Extensions |
| |
| 6.41 Assembler Instructions with C Expression Operands |
| ====================================================== |
| |
| In an assembler instruction using `asm', you can specify the operands |
| of the instruction using C expressions. This means you need not guess |
| which registers or memory locations 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. *Note |
| Extended asm with goto::. |
| |
| Usually the most convenient way to use these `asm' instructions is to |
| encapsulate them in macros that look like functions. For example, |
| |
| #define sin(x) \ |
| ({ double __value, __arg = (x); \ |
| asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ |
| __value; }) |
| |
| Here the variable `__arg' is used to make sure that the instruction |
| operates on a proper `double' value, and to accept only those arguments |
| `x' 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. |
| |
| As of GCC version 4.5, `asm goto' may be used to have the assembly |
| jump to one or more C labels. In this form, a fifth section after the |
| clobber list contains a list of all C labels to which the assembly may |
| jump. Each label operand is implicitly self-named. The `asm' is also |
| assumed to fall through to the next statement. |
| |
| This form of `asm' is restricted to not have outputs. This is due to |
| a internal restriction in the compiler that control transfer |
| instructions cannot have outputs. This restriction on `asm goto' may |
| be lifted in some future version of the compiler. In the mean time, |
| `asm goto' may include a memory clobber, and so leave outputs in memory. |
| |
| int frob(int x) |
| { |
| int y; |
| asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5" |
| : : "r"(x), "r"(&y) : "r5", "memory" : error); |
| return y; |
| error: |
| return -1; |
| } |
| |
| In this (inefficient) example, the `frob' instruction sets the carry |
| bit to indicate an error. The `jc' instruction detects this and |
| branches to the `error' label. Finally, the output of the `frob' |
| instruction (`%r5') is stored into the memory for variable `y', which |
| is later read by the `return' statement. |
| |
| void doit(void) |
| { |
| int i = 0; |
| asm goto ("mfsr %%r1, 123; jmp %%r1;" |
| ".pushsection doit_table;" |
| ".long %l0, %l1, %l2, %l3;" |
| ".popsection" |
| : : : "r1" : label1, label2, label3, label4); |
| __builtin_unreachable (); |
| |
| label1: |
| f1(); |
| return; |
| label2: |
| f2(); |
| return; |
| label3: |
| i = 1; |
| label4: |
| f3(i); |
| } |
| |
| In this (also inefficient) example, the `mfsr' instruction reads an |
| address from some out-of-band machine register, and the following `jmp' |
| instruction branches to that address. The address read by the `mfsr' |
| instruction is assumed to have been previously set via some |
| application-specific mechanism to be one of the four values stored in |
| the `doit_table' section. Finally, the `asm' is followed by a call to |
| `__builtin_unreachable' to indicate that the `asm' does not in fact |
| fall through. |
| |
| #define TRACE1(NUM) \ |
| do { \ |
| asm goto ("0: nop;" \ |
| ".pushsection trace_table;" \ |
| ".long 0b, %l0;" \ |
| ".popsection" \ |
| : : : : trace#NUM); \ |
| if (0) { trace#NUM: trace(); } \ |
| } while (0) |
| #define TRACE TRACE1(__COUNTER__) |
| |
| In this example (which in fact inspired the `asm goto' feature) we |
| want on rare occasions to call the `trace' function; on other occasions |
| we'd like to keep the overhead to the absolute minimum. The normal |
| code path consists of a single `nop' instruction. However, we record |
| the address of this `nop' together with the address of a label that |
| calls the `trace' function. This allows the `nop' instruction to be |
| patched at runtime to be an unconditional branch to the stored label. |
| It is assumed that an optimizing compiler will move the labeled block |
| out of line, to optimize the fall through path from the `asm'. |
| |
| If you are writing a header file that should be includable in ISO C |
| programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::. |
| |
| 6.41.1 Size of an `asm' |
| ----------------------- |
| |
| Some targets require that GCC track the size of each instruction used in |
| order to generate correct code. Because the final length of an `asm' |
| is only known by the assembler, GCC must make an estimate as to how big |
| it will be. The estimate is formed by counting the number of |
| statements in the pattern of the `asm' and multiplying that by the |
| length of the longest instruction on that processor. Statements in the |
| `asm' are identified by newline characters and whatever statement |
| separator characters are supported by the assembler; on most processors |
| this is the ``;'' character. |
| |
| Normally, GCC's estimate is perfectly adequate to ensure that correct |
| code is generated, but it is possible to confuse the compiler if you use |
| pseudo instructions or assembler macros that expand into multiple real |
| instructions or if you use assembler directives that expand to more |
| space in the object file than would be needed for a single instruction. |
| If this happens then the assembler will produce a diagnostic saying that |
| a label is unreachable. |
| |
| 6.41.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)"); |
| |
| |
| File: gcc.info, Node: Constraints, Next: Asm Labels, Prev: Extended Asm, Up: C Extensions |
| |
| 6.42 Constraints for `asm' Operands |
| =================================== |
| |
| Here are specific details on what constraint letters you can use with |
| `asm' operands. Constraints can say whether an operand may be in a |
| register, and which kinds of register; whether the operand can be a |
| memory reference, and which kinds of address; whether the operand may |
| be an immediate constant, and which possible values it may have. |
| Constraints can also require two operands to match. Side-effects |
| aren't allowed in operands of inline `asm', unless `<' or `>' |
| constraints are used, because there is no guarantee that the |
| side-effects will happen exactly once in an instruction that can update |
| the addressing register. |
| |
| * Menu: |
| |
| * Simple Constraints:: Basic use of constraints. |
| * Multi-Alternative:: When an insn has two alternative constraint-patterns. |
| * Modifiers:: More precise control over effects of constraints. |
| * Machine Constraints:: Special constraints for some particular machines. |
| |
| |
| File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints |
| |
| 6.42.1 Simple Constraints |
| ------------------------- |
| |
| The simplest kind of constraint is a string full of letters, each of |
| which describes one kind of operand that is permitted. Here are the |
| letters that are allowed: |
| |
| whitespace |
| Whitespace characters are ignored and can be inserted at any |
| position except the first. This enables each alternative for |
| different operands to be visually aligned in the machine |
| description even if they have different number of constraints and |
| modifiers. |
| |
| `m' |
| A memory operand is allowed, with any kind of address that the |
| machine supports in general. Note that the letter used for the |
| general memory constraint can be re-defined by a back end using |
| the `TARGET_MEM_CONSTRAINT' macro. |
| |
| `o' |
| A memory operand is allowed, but only if the address is |
| "offsettable". This means that adding a small integer (actually, |
| the width in bytes of the operand, as determined by its machine |
| mode) may be added to the address and the result is also a valid |
| memory address. |
| |
| For example, an address which is constant is offsettable; so is an |
| address that is the sum of a register and a constant (as long as a |
| slightly larger constant is also within the range of |
| address-offsets supported by the machine); but an autoincrement or |
| autodecrement address is not offsettable. More complicated |
| indirect/indexed addresses may or may not be offsettable depending |
| on the other addressing modes that the machine supports. |
| |
| Note that in an output operand which can be matched by another |
| operand, the constraint letter `o' is valid only when accompanied |
| by both `<' (if the target machine has predecrement addressing) |
| and `>' (if the target machine has preincrement addressing). |
| |
| `V' |
| A memory operand that is not offsettable. In other words, |
| anything that would fit the `m' constraint but not the `o' |
| constraint. |
| |
| `<' |
| A memory operand with autodecrement addressing (either |
| predecrement or postdecrement) is allowed. In inline `asm' this |
| constraint is only allowed if the operand is used exactly once in |
| an instruction that can handle the side-effects. Not using an |
| operand with `<' in constraint string in the inline `asm' pattern |
| at all or using it in multiple instructions isn't valid, because |
| the side-effects wouldn't be performed or would be performed more |
| than once. Furthermore, on some targets the operand with `<' in |
| constraint string must be accompanied by special instruction |
| suffixes like `%U0' instruction suffix on PowerPC or `%P0' on |
| IA-64. |
| |
| `>' |
| A memory operand with autoincrement addressing (either |
| preincrement or postincrement) is allowed. In inline `asm' the |
| same restrictions as for `<' apply. |
| |
| `r' |
| A register operand is allowed provided that it is in a general |
| register. |
| |
| `i' |
| An immediate integer operand (one with constant value) is allowed. |
| This includes symbolic constants whose values will be known only at |
| assembly time or later. |
| |
| `n' |
| An immediate integer operand with a known numeric value is allowed. |
| Many systems cannot support assembly-time constants for operands |
| less than a word wide. Constraints for these operands should use |
| `n' rather than `i'. |
| |
| `I', `J', `K', ... `P' |
| Other letters in the range `I' through `P' may be defined in a |
| machine-dependent fashion to permit immediate integer operands with |
| explicit integer values in specified ranges. For example, on the |
| 68000, `I' is defined to stand for the range of values 1 to 8. |
| This is the range permitted as a shift count in the shift |
| instructions. |
| |
| `E' |
| An immediate floating operand (expression code `const_double') is |
| allowed, but only if the target floating point format is the same |
| as that of the host machine (on which the compiler is running). |
| |
| `F' |
| An immediate floating operand (expression code `const_double' or |
| `const_vector') is allowed. |
| |
| `G', `H' |
| `G' and `H' may be defined in a machine-dependent fashion to |
| permit immediate floating operands in particular ranges of values. |
| |
| `s' |
| An immediate integer operand whose value is not an explicit |
| integer is allowed. |
| |
| This might appear strange; if an insn allows a constant operand |
| with a value not known at compile time, it certainly must allow |
| any known value. So why use `s' instead of `i'? Sometimes it |
| allows better code to be generated. |
| |
| For example, on the 68000 in a fullword instruction it is possible |
| to use an immediate operand; but if the immediate value is between |
| -128 and 127, better code results from loading the value into a |
| register and using the register. This is because the load into |
| the register can be done with a `moveq' instruction. We arrange |
| for this to happen by defining the letter `K' to mean "any integer |
| outside the range -128 to 127", and then specifying `Ks' in the |
| operand constraints. |
| |
| `g' |
| Any register, memory or immediate integer operand is allowed, |
| except for registers that are not general registers. |
| |
| `X' |
| Any operand whatsoever is allowed. |
| |
| `0', `1', `2', ... `9' |
| An operand that matches the specified operand number is allowed. |
| If a digit is used together with letters within the same |
| alternative, the digit should come last. |
| |
| This number is allowed to be more than a single digit. If multiple |
| digits are encountered consecutively, they are interpreted as a |
| single decimal integer. There is scant chance for ambiguity, |
| since to-date it has never been desirable that `10' be interpreted |
| as matching either operand 1 _or_ operand 0. Should this be |
| desired, one can use multiple alternatives instead. |
| |
| This is called a "matching constraint" and what it really means is |
| that the assembler has only a single operand that fills two roles |
| which `asm' distinguishes. For example, an add instruction uses |
| two input operands and an output operand, but on most CISC |
| machines an add instruction really has only two operands, one of |
| them an input-output operand: |
| |
| addl #35,r12 |
| |
| Matching constraints are used in these circumstances. More |
| precisely, the two operands that match must include one input-only |
| operand and one output-only operand. Moreover, the digit must be a |
| smaller number than the number of the operand that uses it in the |
| constraint. |
| |
| `p' |
| An operand that is a valid memory address is allowed. This is for |
| "load address" and "push address" instructions. |
| |
| `p' in the constraint must be accompanied by `address_operand' as |
| the predicate in the `match_operand'. This predicate interprets |
| the mode specified in the `match_operand' as the mode of the memory |
| reference for which the address would be valid. |
| |
| OTHER-LETTERS |
| Other letters can be defined in machine-dependent fashion to stand |
| for particular classes of registers or other arbitrary operand |
| types. `d', `a' and `f' are defined on the 68000/68020 to stand |
| for data, address and floating point registers. |
| |
| |
| File: gcc.info, Node: Multi-Alternative, Next: Modifiers, Prev: Simple Constraints, Up: Constraints |
| |
| 6.42.2 Multiple Alternative Constraints |
| --------------------------------------- |
| |
| Sometimes a single instruction has multiple alternative sets of possible |
| operands. For example, on the 68000, a logical-or instruction can |
| combine register or an immediate value into memory, or it can combine |
| any kind of operand into a register; but it cannot combine one memory |
| location into another. |
| |
| These constraints are represented as multiple alternatives. An |
| alternative can be described by a series of letters for each operand. |
| The overall constraint for an operand is made from the letters for this |
| operand from the first alternative, a comma, the letters for this |
| operand from the second alternative, a comma, and so on until the last |
| alternative. |
| |
| If all the operands fit any one alternative, the instruction is valid. |
| Otherwise, for each alternative, the compiler counts how many |
| instructions must be added to copy the operands so that that |
| alternative applies. The alternative requiring the least copying is |
| chosen. If two alternatives need the same amount of copying, the one |
| that comes first is chosen. These choices can be altered with the `?' |
| and `!' characters: |
| |
| `?' |
| Disparage slightly the alternative that the `?' appears in, as a |
| choice when no alternative applies exactly. The compiler regards |
| this alternative as one unit more costly for each `?' that appears |
| in it. |
| |
| `!' |
| Disparage severely the alternative that the `!' appears in. This |
| alternative can still be used if it fits without reloading, but if |
| reloading is needed, some other alternative will be used. |
| |
| |
| File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Multi-Alternative, Up: Constraints |
| |
| 6.42.3 Constraint Modifier Characters |
| ------------------------------------- |
| |
| Here are constraint modifier characters. |
| |
| `=' |
| Means that this operand is write-only for this instruction: the |
| previous value is discarded and replaced by output data. |
| |
| `+' |
| Means that this operand is both read and written by the |
| instruction. |
| |
| When the compiler fixes up the operands to satisfy the constraints, |
| it needs to know which operands are inputs to the instruction and |
| which are outputs from it. `=' identifies an output; `+' |
| identifies an operand that is both input and output; all other |
| operands are assumed to be input only. |
| |
| If you specify `=' or `+' in a constraint, you put it in the first |
| character of the constraint string. |
| |
| `&' |
| Means (in a particular alternative) that this operand is an |
| "earlyclobber" operand, which is modified before the instruction is |
| finished using the input operands. Therefore, this operand may |
| not lie in a register that is used as an input operand or as part |
| of any memory address. |
| |
| `&' applies only to the alternative in which it is written. In |
| constraints with multiple alternatives, sometimes one alternative |
| requires `&' while others do not. See, for example, the `movdf' |
| insn of the 68000. |
| |
| An input operand can be tied to an earlyclobber operand if its only |
| use as an input occurs before the early result is written. Adding |
| alternatives of this form often allows GCC to produce better code |
| when only some of the inputs can be affected by the earlyclobber. |
| See, for example, the `mulsi3' insn of the ARM. |
| |
| `&' does not obviate the need to write `='. |
| |
| `%' |
| Declares the instruction to be commutative for this operand and the |
| following operand. This means that the compiler may interchange |
| the two operands if that is the cheapest way to make all operands |
| fit the constraints. GCC can only handle one commutative pair in |
| an asm; if you use more, the compiler may fail. Note that you |
| need not use the modifier if the two alternatives are strictly |
| identical; this would only waste time in the reload pass. The |
| modifier is not operational after register allocation, so the |
| result of `define_peephole2' and `define_split's performed after |
| reload cannot rely on `%' to make the intended insn match. |
| |
| `#' |
| Says that all following characters, up to the next comma, are to be |
| ignored as a constraint. They are significant only for choosing |
| register preferences. |
| |
| `*' |
| Says that the following character should be ignored when choosing |
| register preferences. `*' has no effect on the meaning of the |
| constraint as a constraint, and no effect on reloading. |
| |
| |
| |
| File: gcc.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints |
| |
| 6.42.4 Constraints for Particular Machines |
| ------------------------------------------ |
| |
| Whenever possible, you should use the general-purpose constraint letters |
| in `asm' arguments, since they will convey meaning more readily to |
| people reading your code. Failing that, use the constraint letters |
| that usually have very similar meanings across architectures. The most |
| commonly used constraints are `m' and `r' (for memory and |
| general-purpose registers respectively; *note Simple Constraints::), and |
| `I', usually the letter indicating the most common immediate-constant |
| format. |
| |
| Each architecture defines additional constraints. These constraints |
| are used by the compiler itself for instruction generation, as well as |
| for `asm' statements; therefore, some of the constraints are not |
| particularly useful for `asm'. Here is a summary of some of the |
| machine-dependent constraints available on some particular machines; it |
| includes both constraints that are useful for `asm' and constraints |
| that aren't. The compiler source file mentioned in the table heading |
| for each architecture is the definitive reference for the meanings of |
| that architecture's constraints. |
| |
| _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 |
| |
| `d' |
| Floating point register (containing 64-bit value) |
| |
| `f' |
| Floating point register (containing 32-bit value) |
| |
| `v' |
| Altivec vector register |
| |
| `wd' |
| VSX vector register to hold vector double data |
| |
| `wf' |
| VSX vector register to hold vector float data |
| |
| `ws' |
| VSX vector register to hold scalar float data |
| |
| `wa' |
| Any VSX 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' |
| `XER[CA]' carry bit (part of the XER register) |
| |
| `I' |
| Signed 16-bit constant |
| |
| `J' |
| Unsigned 16-bit constant shifted left 16 bits (use `L' |
| instead for `SImode' constants) |
| |
| `K' |
| Unsigned 16-bit constant |
| |
| `L' |
| Signed 16-bit constant shifted left 16 bits |
| |
| `M' |
| Constant larger than 31 |
| |
| `N' |
| Exact power of 2 |
| |
| `O' |
| Zero |
| |
| `P' |
| Constant whose negation is a signed 16-bit constant |
| |
| `G' |
| Floating point constant that can be loaded into a register |
| with one instruction per word |
| |
| `H' |
| Integer/Floating point constant that can be loaded into a |
| register using three instructions |
| |
| `m' |
| Memory operand. Normally, `m' does not allow addresses that |
| update the base register. If `<' or `>' constraint is also |
| used, they are allowed and therefore on PowerPC targets in |
| that case it is only safe to use `m<>' in an `asm' statement |
| if that `asm' statement accesses the operand exactly once. |
| The `asm' statement must also use `%U<OPNO>' as a placeholder |
| for the "update" flag in the corresponding load or store |
| instruction. For example: |
| |
| asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); |
| |
| is correct but: |
| |
| asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); |
| |
| is not. |
| |
| `es' |
| A "stable" memory operand; that is, one which does not |
| include any automodification of the base register. This used |
| to be useful when `m' allowed automodification of the base |
| register, but as those are now only allowed when `<' or `>' |
| is used, `es' is basically the same as `m' without `<' and |
| `>'. |
| |
| `Q' |
| Memory operand that is an offset from a register (it is |
| usually better to use `m' or `es' in `asm' statements) |
| |
| `Z' |
| Memory operand that is an indexed or indirect from a register |
| (it is usually better to use `m' or `es' in `asm' statements) |
| |
| `R' |
| AIX TOC entry |
| |
| `a' |
| Address operand that is an indexed or indirect from a |
| register (`p' is preferable for `asm' statements) |
| |
| `S' |
| Constant suitable as a 64-bit mask operand |
| |
| `T' |
| Constant suitable as a 32-bit mask operand |
| |
| `U' |
| System V Release 4 small data area reference |
| |
| `t' |
| AND masks that can be performed by two rldic{l, r} |
| instructions |
| |
| `W' |
| Vector constant that does not require memory |
| |
| `j' |
| Vector constant that is all zeros. |
| |
| |
| _Intel 386--`config/i386/constraints.md'_ |
| |
| `R' |
| Legacy register--the eight integer registers available on all |
| i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). |
| |
| `q' |
| Any register accessible as `Rl'. In 32-bit mode, `a', `b', |
| `c', and `d'; in 64-bit mode, any integer register. |
| |
| `Q' |
| Any register accessible as `Rh': `a', `b', `c', and `d'. |
| |
| `a' |
| The `a' register. |
| |
| `b' |
| The `b' register. |
| |
| `c' |
| The `c' register. |
| |
| `d' |
| The `d' register. |
| |
| `S' |
| The `si' register. |
| |
| `D' |
| The `di' register. |
| |
| `A' |
| The `a' and `d' registers. This class is used for |
| instructions that return double word results in the `ax:dx' |
| register pair. Single word values will be allocated either |
| in `ax' or `dx'. For example on i386 the following |
| implements `rdtsc': |
| |
| unsigned long long rdtsc (void) |
| { |
| unsigned long long tick; |
| __asm__ __volatile__("rdtsc":"=A"(tick)); |
| return tick; |
| } |
| |
| This is not correct on x86_64 as it would allocate tick in |
| either `ax' or `dx'. You have to use the following variant |
| instead: |
| |
| unsigned long long rdtsc (void) |
| { |
| unsigned int tickl, tickh; |
| __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); |
| return ((unsigned long long)tickh << 32)|tickl; |
| } |
| |
| `f' |
| Any 80387 floating-point (stack) register. |
| |
| `t' |
| Top of 80387 floating-point stack (`%st(0)'). |
| |
| `u' |
| Second from top of 80387 floating-point stack (`%st(1)'). |
| |
| `y' |
| Any MMX register. |
| |
| `x' |
| Any SSE register. |
| |
| `Yz' |
| First SSE register (`%xmm0'). |
| |
| `I' |
| Integer constant in the range 0 ... 31, for 32-bit shifts. |
| |
| `J' |
| Integer constant in the range 0 ... 63, for 64-bit shifts. |
| |
| `K' |
| Signed 8-bit integer constant. |
| |
| `L' |
| `0xFF' or `0xFFFF', for andsi as a zero-extending move. |
| |
| `M' |
| 0, 1, 2, or 3 (shifts for the `lea' instruction). |
| |
| `N' |
| Unsigned 8-bit integer constant (for `in' and `out' |
| instructions). |
| |
| `G' |
| Standard 80387 floating point constant. |
| |
| `C' |
| Standard SSE floating point constant. |
| |
| `e' |
| 32-bit signed integer constant, or a symbolic reference known |
| to fit that range (for immediate operands in sign-extending |
| x86-64 instructions). |
| |
| `Z' |
| 32-bit unsigned integer constant, or a symbolic reference |
| known to fit that range (for immediate operands in |
| zero-extending x86-64 instructions). |
| |
| |
| _Intel IA-64--`config/ia64/ia64.h'_ |
| |
| `a' |
| General register `r0' to `r3' for `addl' instruction |
| |
| `b' |
| Branch register |
| |
| `c' |
| Predicate register (`c' as in "conditional") |
| |
| `d' |
| Application register residing in M-unit |
| |
| `e' |
| Application register residing in I-unit |
| |
| `f' |
| Floating-point register |
| |
| `m' |
| Memory operand. If used together with `<' or `>', the |
| operand can have postincrement and postdecrement which |
| require printing with `%Pn' on IA-64. |
| |
| `G' |
| Floating-point constant 0.0 or 1.0 |
| |
| `I' |
| 14-bit signed integer constant |
| |
| `J' |
| 22-bit signed integer constant |
| |
| `K' |
| 8-bit signed integer constant for logical instructions |
| |
| `L' |
| 8-bit adjusted signed integer constant for compare pseudo-ops |
| |
| `M' |
| 6-bit unsigned integer constant for shift counts |
| |
| `N' |
| 9-bit signed integer constant for load and store |
| postincrements |
| |
| `O' |
| The constant zero |
| |
| `P' |
| 0 or -1 for `dep' instruction |
| |
| `Q' |
| Non-volatile memory for floating-point loads and stores |
| |
| `R' |
| Integer constant in the range 1 to 4 for `shladd' instruction |
| |
| `S' |
| Memory operand except postincrement and postdecrement. This |
| is now roughly the same as `m' when not used together with `<' |
| or `>'. |
| |
| _FRV--`config/frv/frv.h'_ |
| |
| `a' |
| Register in the class `ACC_REGS' (`acc0' to `acc7'). |
| |
| `b' |
| Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). |
| |
| `c' |
| Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' |
| to `icc3'). |
| |
| `d' |
| Register in the class `GPR_REGS' (`gr0' to `gr63'). |
| |
| `e' |
| Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd |
| registers are excluded not in the class but through the use |
| of a machine mode larger than 4 bytes. |
| |
| `f' |
| Register in the class `FPR_REGS' (`fr0' to `fr63'). |
| |
| `h' |
| Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd |
| registers are excluded not in the class but through the use |
| of a machine mode larger than 4 bytes. |
| |
| `l' |
| Register in the class `LR_REG' (the `lr' register). |
| |
| `q' |
| Register in the class `QUAD_REGS' (`gr2' to `gr63'). |
| Register numbers not divisible by 4 are excluded not in the |
| class but through the use of a machine mode larger than 8 |
| bytes. |
| |
| `t' |
| Register in the class `ICC_REGS' (`icc0' to `icc3'). |
| |
| `u' |
| Register in the class `FCC_REGS' (`fcc0' to `fcc3'). |
| |
| `v' |
| Register in the class `ICR_REGS' (`cc4' to `cc7'). |
| |
| `w' |
| Register in the class `FCR_REGS' (`cc0' to `cc3'). |
| |
| `x' |
| Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). |
| Register numbers not divisible by 4 are excluded not in the |
| class but through the use of a machine mode larger than 8 |
| bytes. |
| |
| `z' |
| Register in the class `SPR_REGS' (`lcr' and `lr'). |
| |
| `A' |
| Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). |
| |
| `B' |
| Register in the class `ACCG_REGS' (`accg0' to `accg7'). |
| |
| `C' |
| Register in the class `CR_REGS' (`cc0' to `cc7'). |
| |
| `G' |
| Floating point constant zero |
| |
| `I' |
| 6-bit signed integer constant |
| |
| `J' |
| 10-bit signed integer constant |
| |
| `L' |
| 16-bit signed integer constant |
| |
| `M' |
| 16-bit unsigned integer constant |
| |
| `N' |
| 12-bit signed integer constant that is negative--i.e. in the |
| range of -2048 to -1 |
| |
| `O' |
| Constant zero |
| |
| `P' |
| 12-bit signed integer constant that is greater than |
| zero--i.e. in the range of 1 to 2047. |
| |
| |
| _Blackfin family--`config/bfin/constraints.md'_ |
| |
| `a' |
| P register |
| |
| `d' |
| D register |
| |
| `z' |
| A call clobbered P register. |
| |
| `qN' |
| A single register. If N is in the range 0 to 7, the |
| corresponding D register. If it is `A', then the register P0. |
| |
| `D' |
| Even-numbered D register |
| |
| `W' |
| Odd-numbered D register |
| |
| `e' |
| Accumulator register. |
| |
| `A' |
| Even-numbered accumulator register. |
| |
| `B' |
| Odd-numbered accumulator register. |
| |
| `b' |
| I register |
| |
| `v' |
| B register |
| |
| `f' |
| M register |
| |
| `c' |
| Registers used for circular buffering, i.e. I, B, or L |
| registers. |
| |
| `C' |
| The CC register. |
| |
| `t' |
| LT0 or LT1. |
| |
| `k' |
| LC0 or LC1. |
| |
| `u' |
| LB0 or LB1. |
| |
| `x' |
| Any D, P, B, M, I or L register. |
| |
| `y' |
| Additional registers typically used only in prologues and |
| epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and |
| USP. |
| |
| `w' |
| Any register except accumulators or CC. |
| |
| `Ksh' |
| Signed 16 bit integer (in the range -32768 to 32767) |
| |
| `Kuh' |
| Unsigned 16 bit integer (in the range 0 to 65535) |
| |
| `Ks7' |
| Signed 7 bit integer (in the range -64 to 63) |
| |
| `Ku7' |
| Unsigned 7 bit integer (in the range 0 to 127) |
| |
| `Ku5' |
| Unsigned 5 bit integer (in the range 0 to 31) |
| |
| `Ks4' |
| Signed 4 bit integer (in the range -8 to 7) |
| |
| `Ks3' |
| Signed 3 bit integer (in the range -3 to 4) |
| |
| `Ku3' |
| Unsigned 3 bit integer (in the range 0 to 7) |
| |
| `PN' |
| Constant N, where N is a single-digit constant in the range 0 |
| to 4. |
| |
| `PA' |
| An integer equal to one of the MACFLAG_XXX constants that is |
| suitable for use with either accumulator. |
| |
| `PB' |
| An integer equal to one of the MACFLAG_XXX constants that is |
| suitable for use only with accumulator A1. |
| |
| `M1' |
| Constant 255. |
| |
| `M2' |
| Constant 65535. |
| |
| `J' |
| An integer constant with exactly a single bit set. |
| |
| `L' |
| An integer constant with all bits set except exactly one. |
| |
| `H' |
| |
| `Q' |
| Any SYMBOL_REF. |
| |
| _M32C--`config/m32c/m32c.c'_ |
| |
| `Rsp' |
| `Rfb' |
| `Rsb' |
| `$sp', `$fb', `$sb'. |
| |
| `Rcr' |
| Any control register, when they're 16 bits wide (nothing if |
| control registers are 24 bits wide) |
| |
| `Rcl' |
| Any control register, when they're 24 bits wide. |
| |
| `R0w' |
| `R1w' |
| `R2w' |
| `R3w' |
| $r0, $r1, $r2, $r3. |
| |
| `R02' |
| $r0 or $r2, or $r2r0 for 32 bit values. |
| |
| `R13' |
| $r1 or $r3, or $r3r1 for 32 bit values. |
| |
| `Rdi' |
| A register that can hold a 64 bit value. |
| |
| `Rhl' |
| $r0 or $r1 (registers with addressable high/low bytes) |
| |
| `R23' |
| $r2 or $r3 |
| |
| `Raa' |
| Address registers |
| |
| `Raw' |
| Address registers when they're 16 bits wide. |
| |
| `Ral' |
| Address registers when they're 24 bits wide. |
| |
| `Rqi' |
| Registers that can hold QI values. |
| |
| `Rad' |
| Registers that can be used with displacements ($a0, $a1, $sb). |
| |
| `Rsi' |
| Registers that can hold 32 bit values. |
| |
| `Rhi' |
| Registers that can hold 16 bit values. |
| |
| `Rhc' |
| Registers chat can hold 16 bit values, including all control |
| registers. |
| |
| `Rra' |
| $r0 through R1, plus $a0 and $a1. |
| |
| `Rfl' |
| The flags register. |
| |
| `Rmm' |
| The memory-based pseudo-registers $mem0 through $mem15. |
| |
| `Rpi' |
| Registers that can hold pointers (16 bit registers for r8c, |
| m16c; 24 bit registers for m32cm, m32c). |
| |
| `Rpa' |
| Matches multiple registers in a PARALLEL to form a larger |
| register. Used to match function return values. |
| |
| `Is3' |
| -8 ... 7 |
| |
| `IS1' |
| -128 ... 127 |
| |
| `IS2' |
| -32768 ... 32767 |
| |
| `IU2' |
| 0 ... 65535 |
| |
| `In4' |
| -8 ... -1 or 1 ... 8 |
| |
| `In5' |
| -16 ... -1 or 1 ... 16 |
| |
| `In6' |
| -32 ... -1 or 1 ... 32 |
| |
| `IM2' |
| -65536 ... -1 |
| |
| `Ilb' |
| An 8 bit value with exactly one bit set. |
| |
| `Ilw' |
| A 16 bit value with exactly one bit set. |
| |
| `Sd' |
| The common src/dest memory addressing modes. |
| |
| `Sa' |
| Memory addressed using $a0 or $a1. |
| |
| `Si' |
| Memory addressed with immediate addresses. |
| |
| `Ss' |
| Memory addressed using the stack pointer ($sp). |
| |
| `Sf' |
| Memory addressed using the frame base register ($fb). |
| |
| `Ss' |
| Memory addressed using the small base register ($sb). |
| |
| `S1' |
| $r1h |
| |
| _MeP--`config/mep/constraints.md'_ |
| |
| `a' |
| The $sp register. |
| |
| `b' |
| The $tp register. |
| |
| `c' |
| Any control register. |
| |
| `d' |
| Either the $hi or the $lo register. |
| |
| `em' |
| Coprocessor registers that can be directly loaded ($c0-$c15). |
| |
| `ex' |
| Coprocessor registers that can be moved to each other. |
| |
| `er' |
| Coprocessor registers that can be moved to core registers. |
| |
| `h' |
| The $hi register. |
| |
| `j' |
| The $rpc register. |
| |
| `l' |
| The $lo register. |
| |
| `t' |
| Registers which can be used in $tp-relative addressing. |
| |
| `v' |
| The $gp register. |
| |
| `x' |
| The coprocessor registers. |
| |
| `y' |
| The coprocessor control registers. |
| |
| `z' |
| The $0 register. |
| |
| `A' |
| User-defined register set A. |
| |
| `B' |
| User-defined register set B. |
| |
| `C' |
| User-defined register set C. |
| |
| `D' |
| User-defined register set D. |
| |
| `I' |
| Offsets for $gp-rel addressing. |
| |
| `J' |
| Constants that can be used directly with boolean insns. |
| |
| `K' |
| Constants that can be moved directly to registers. |
| |
| `L' |
| Small constants that can be added to registers. |
| |
| `M' |
| Long shift counts. |
| |
| `N' |
| Small constants that can be compared to registers. |
| |
| `O' |
| Constants that can be loaded into the top half of registers. |
| |
| `S' |
| Signed 8-bit immediates. |
| |
| `T' |
| Symbols encoded for $tp-rel or $gp-rel addressing. |
| |
| `U' |
| Non-constant addresses for loading/saving coprocessor |
| registers. |
| |
| `W' |
| The top half of a symbol's value. |
| |
| `Y' |
| A register indirect address without offset. |
| |
| `Z' |
| Symbolic references to the control bus. |
| |
| |
| _MicroBlaze--`config/microblaze/constraints.md'_ |
| |
| `d' |
| A general register (`r0' to `r31'). |
| |
| `z' |
| A status register (`rmsr', `$fcc1' to `$fcc7'). |
| |
| |
| _MIPS--`config/mips/constraints.md'_ |
| |
| `d' |
| An address register. This is equivalent to `r' unless |
| generating MIPS16 code. |
| |
| `f' |
| A floating-point register (if available). |
| |
| `h' |
| Formerly the `hi' register. This constraint is no longer |
| supported. |
| |
| `l' |
| The `lo' register. Use this register to store values that are |
| no bigger than a word. |
| |
| `x' |
| The concatenated `hi' and `lo' registers. Use this register |
| to store doubleword values. |
| |
| `c' |
| A register suitable for use in an indirect jump. This will |
| always be `$25' for `-mabicalls'. |
| |
| `v' |
| Register `$3'. Do not use this constraint in new code; it is |
| retained only for compatibility with glibc. |
| |
| `y' |
| Equivalent to `r'; retained for backwards compatibility. |
| |
| `z' |
| A floating-point condition code register. |
| |
| `I' |
| A signed 16-bit constant (for arithmetic instructions). |
| |
| `J' |
| Integer zero. |
| |
| `K' |
| An unsigned 16-bit constant (for logic instructions). |
| |
| `L' |
| A signed 32-bit constant in which the lower 16 bits are zero. |
| Such constants can be loaded using `lui'. |
| |
| `M' |
| A constant that cannot be loaded using `lui', `addiu' or |
| `ori'. |
| |
| `N' |
| A constant in the range -65535 to -1 (inclusive). |
| |
| `O' |
| A signed 15-bit constant. |
| |
| `P' |
| A constant in the range 1 to 65535 (inclusive). |
| |
| `G' |
| Floating-point zero. |
| |
| `R' |
| An address that can be used in a non-macro load or store. |
| |
| _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 |
| |
| |
| _Moxie--`config/moxie/constraints.md'_ |
| |
| `A' |
| An absolute address |
| |
| `B' |
| An offset address |
| |
| `W' |
| A register indirect memory operand |
| |
| `I' |
| A constant in the range of 0 to 255. |
| |
| `N' |
| A constant in the range of 0 to -255. |
| |
| |
| _PDP-11--`config/pdp11/constraints.md'_ |
| |
| `a' |
| Floating point registers AC0 through AC3. These can be |
| loaded from/to memory with a single instruction. |
| |
| `d' |
| Odd numbered general registers (R1, R3, R5). These are used |
| for 16-bit multiply operations. |
| |
| `f' |
| Any of the floating point registers (AC0 through AC5). |
| |
| `G' |
| Floating point constant 0. |
| |
| `I' |
| An integer constant that fits in 16 bits. |
| |
| `J' |
| An integer constant whose low order 16 bits are zero. |
| |
| `K' |
| An integer constant that does not meet the constraints for |
| codes `I' or `J'. |
| |
| `L' |
| The integer constant 1. |
| |
| `M' |
| The integer constant -1. |
| |
| `N' |
| The integer constant 0. |
| |
| `O' |
| Integer constants -4 through -1 and 1 through 4; shifts by |
| these amounts are handled as multiple single-bit shifts |
| rather than a single variable-length shift. |
| |
| `Q' |
| A memory reference which requires an additional word (address |
| or offset) after the opcode. |
| |
| `R' |
| A memory reference that is encoded within the opcode. |
| |
| |
| _RX--`config/rx/constraints.md'_ |
| |
| `Q' |
| An address which does not involve register indirect |
| addressing or pre/post increment/decrement addressing. |
| |
| `Symbol' |
| A symbol reference. |
| |
| `Int08' |
| A constant in the range -256 to 255, inclusive. |
| |
| `Sint08' |
| A constant in the range -128 to 127, inclusive. |
| |
| `Sint16' |
| A constant in the range -32768 to 32767, inclusive. |
| |
| `Sint24' |
| A constant in the range -8388608 to 8388607, inclusive. |
| |
| `Uint04' |
| A constant in the range 0 to 15, inclusive. |
| |
| |
| _SPARC--`config/sparc/sparc.h'_ |
| |
| `f' |
| Floating-point register on the SPARC-V8 architecture and |
| lower floating-point register on the SPARC-V9 architecture. |
| |
| `e' |
| Floating-point register. It is equivalent to `f' on the |
| SPARC-V8 architecture and contains both lower and upper |
| floating-point registers on the SPARC-V9 architecture. |
| |
| `c' |
| Floating-point condition code register. |
| |
| `d' |
| Lower floating-point register. It is only valid on the |
| SPARC-V9 architecture when the Visual Instruction Set is |
| available. |
| |
| `b' |
| Floating-point register. It is only valid on the SPARC-V9 |
| architecture when the Visual Instruction Set is available. |
| |
| `h' |
| 64-bit global or out register for the SPARC-V8+ architecture. |
| |
| `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 |
| |
| |
| |
| |
| File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Constraints, Up: C Extensions |
| |
| 6.43 Controlling Names Used in Assembler Code |
| ============================================= |
| |
| You can specify the name to be used in the assembler code for a C |
| function or variable by writing the `asm' (or `__asm__') keyword after |
| the declarator as follows: |
| |
| int foo asm ("myfoo") = 2; |
| |
| This specifies that the name to be used for the variable `foo' in the |
| assembler code should be `myfoo' rather than the usual `_foo'. |
| |
| On systems where an underscore is normally prepended to the name of a C |
| function or variable, this feature allows you to define names for the |
| linker that do not start with an underscore. |
| |
| It does not make sense to use this feature with a non-static local |
| variable since such variables do not have assembler names. If you are |
| trying to put the variable in a particular register, see *note Explicit |
| Reg Vars::. GCC presently accepts such code with a warning, but will |
| probably be changed to issue an error, rather than a warning, in the |
| future. |
| |
| You cannot use `asm' in this way in a function _definition_; but you |
| can get the same effect by writing a declaration for the function |
| before its definition and putting `asm' there, like this: |
| |
| extern func () asm ("FUNC"); |
| |
| func (x, y) |
| int x, y; |
| /* ... */ |
| |
| It is up to you to make sure that the assembler names you choose do not |
| conflict with any other assembler symbols. Also, you must not use a |
| register name; that would produce completely invalid assembler code. |
| GCC does not as yet have the ability to store static variables in |
| registers. Perhaps that will be added. |
| |
| |
| File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions |
| |
| 6.44 Variables in Specified Registers |
| ===================================== |
| |
| GNU C allows you to put a few global variables into specified hardware |
| registers. You can also specify the register in which an ordinary |
| register variable should be allocated. |
| |
| * Global register variables reserve registers throughout the program. |
| This may be useful in programs such as programming language |
| interpreters 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:: |
| |
| |
| File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars |
| |
| 6.44.1 Defining Global Register Variables |
| ----------------------------------------- |
| |
| You can define a global register variable in GNU C like this: |
| |
| register int *foo asm ("a5"); |
| |
| Here `a5' is the name of the register 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. |
| |
| |
| File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars |
| |
| 6.44.2 Specifying Registers for Local Variables |
| ----------------------------------------------- |
| |
| You can define a local register variable with a specified register like |
| this: |
| |
| register int *foo asm ("a5"); |
| |
| Here `a5' is the name of the register 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::. |
| |
| |
| File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions |
| |
| 6.45 Alternate Keywords |
| ======================= |
| |
| `-ansi' and the various `-std' options disable certain keywords. This |
| causes trouble when you want to use GNU C extensions, or a |
| general-purpose header file that should be usable by all programs, |
| including ISO C programs. The keywords `asm', `typeof' and `inline' |
| are not available in programs compiled with `-ansi' or `-std' (although |
| `inline' can be used in a program compiled with `-std=c99' or |
| `-std=c1x'). The ISO C99 keyword `restrict' is only available when |
| `-std=gnu99' (which will eventually be the default) or `-std=c99' (or |
| the equivalent `-std=iso9899:1999'), or an option for a later standard |
| version, is used. |
| |
| The way to solve these problems is to put `__' at the beginning and |
| end of each problematical keyword. For example, use `__asm__' instead |
| of `asm', and `__inline__' instead of `inline'. |
| |
| Other C compilers won't accept these alternative keywords; if you want |
| to compile with another compiler, you can define the alternate keywords |
| as macros to replace them with the customary keywords. It looks like |
| this: |
| |
| #ifndef __GNUC__ |
| #define __asm__ asm |
| #endif |
| |
| `-pedantic' and other options cause warnings for many GNU C extensions. |
| You can prevent such warnings within one expression by writing |
| `__extension__' before the expression. `__extension__' has no effect |
| aside from this. |
| |
| |
| File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions |
| |
| 6.46 Incomplete `enum' Types |
| ============================ |
| |
| You can define an `enum' tag without specifying its possible values. |
| This results in an incomplete type, much like what you get if you write |
| `struct foo' without describing the elements. A later declaration |
| 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++. |
| |
| |
| File: gcc.info, Node: Function Names, Next: Return Address, Prev: Incomplete Enums, Up: C Extensions |
| |
| 6.47 Function Names as Strings |
| ============================== |
| |
| GCC provides three magic variables 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. |
| |
| |
| File: gcc.info, Node: Return Address, Next: Vector Extensions, Prev: Function Names, Up: C Extensions |
| |
| 6.48 Getting the Return or Frame Address of a Function |
| ====================================================== |
| |
| These functions may be used to get information about the callers of a |
| function. |
| |
| -- Built-in Function: void * __builtin_return_address (unsigned int |
| LEVEL) |
| This function returns the return address of the current function, |
| or of one of its callers. The LEVEL argument is number of frames |
| to scan up the call stack. A value of `0' yields the return |
| address of the current function, a value of `1' yields the return |
| address of the caller of the current function, and so forth. When |
| inlining the expected behavior is that the function 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. |
| |
| Additional post-processing of the returned value may be needed, see |
| `__builtin_extract_return_address'. |
| |
| This function should only be used with a nonzero argument for |
| debugging purposes. |
| |
| -- Built-in Function: void * __builtin_extract_return_address (void |
| *ADDR) |
| The address as returned by `__builtin_return_address' may have to |
| be fed through this function to get the actual encoded address. |
| For example, on the 31-bit S/390 platform the highest bit has to |
| be masked out, or on SPARC platforms an offset has to be added for |
| the true next instruction to be executed. |
| |
| If no fixup is needed, this function simply passes through ADDR. |
| |
| -- Built-in Function: void * __builtin_frob_return_address (void *ADDR) |
| This function does the reverse of |
| `__builtin_extract_return_address'. |
| |
| -- 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. |
| |
| |
| File: gcc.info, Node: Vector Extensions, Next: Offsetof, Prev: Return Address, Up: C Extensions |
| |
| 6.49 Using vector instructions through built-in functions |
| ========================================================= |
| |
| On some targets, the instruction set contains SIMD vector instructions |
| 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. |
| |
| In C it is possible to use shifting operators `<<', `>>' on |
| integer-type vectors. The operation is defined as following: `{a0, a1, |
| ..., an} >> {b0, b1, ..., bn} == {a0 >> b0, a1 >> b1, ..., an >> bn}'. |
| Vector operands must have the same number of elements. Additionally |
| second operands can be a scalar integer in which case the scalar is |
| converted to the type used by the vector operand (with possible |
| truncation) and each element of this new vector is the scalar's value. |
| Consider the following code. |
| |
| typedef int v4si __attribute__ ((vector_size (16))); |
| |
| v4si a, b; |
| |
| b = a >> 1; /* b = a >> {1,1,1,1}; */ |
| |
| In C vectors can be subscripted as if the vector were an array with |
| the same number of elements and base type. Out of bound accesses |
| invoke undefined behavior at runtime. Warnings for out of bound |
| accesses for vector subscription can be enabled with `-Warray-bounds'. |
| |
| 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); |
| } |
| |
| |
| File: gcc.info, Node: Offsetof, Next: Atomic Builtins, Prev: Vector Extensions, Up: C Extensions |
| |
| 6.50 Offsetof |
| ============= |
| |
| GCC implements for both C and C++ a syntactic extension to implement |
| the `offsetof' macro. |
| |
| primary: |
| "__builtin_offsetof" "(" `typename' "," offsetof_member_designator ")" |
| |
| offsetof_member_designator: |
| `identifier' |
| | offsetof_member_designator "." `identifier' |
| | offsetof_member_designator "[" `expr' "]" |
| |
| This extension is sufficient such that |
| |
| #define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER) |
| |
| is a suitable definition of the `offsetof' macro. In C++, TYPE may be |
| dependent. In either case, MEMBER may consist of a single identifier, |
| or a sequence of member accesses and array references. |
| |
| |
| File: gcc.info, Node: Atomic Builtins, Next: Object Size Checking, Prev: Offsetof, Up: C Extensions |
| |
| 6.51 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. |
| |
| |
| File: gcc.info, Node: Object Size Checking, Next: Other Builtins, Prev: Atomic Builtins, Up: C Extensions |
| |
| 6.52 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. |
| |
| |
| File: gcc.info, Node: Other Builtins, Next: Target Builtins, Prev: Object Size Checking, Up: C Extensions |
| |
| 6.53 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=c90', `-std=c99' or |
| `-std=c1x'), the functions `_exit', `alloca', `bcmp', `bzero', |
| `dcgettext', `dgettext', `dremf', `dreml', `drem', `exp10f', `exp10l', |
| `exp10', `ffsll', `ffsl', `ffs', `fprintf_unlocked', `fputs_unlocked', |
| `gammaf', `gammal', `gamma', `gammaf_r', `gammal_r', `gamma_r', |
| `gettext', `index', `isascii', `j0f', `j0l', `j0', `j1f', `j1l', `j1', |
| `jnf', `jnl', `jn', `lgammaf_r', `lgammal_r', `lgamma_r', `mempcpy', |
| `pow10f', `pow10l', `pow10', `printf_unlocked', `rindex', `scalbf', |
| `scalbl', `scalb', `signbit', `signbitf', `signbitl', `signbitd32', |
| `signbitd64', `signbitd128', `significandf', `significandl', |
| `significand', `sincosf', `sincosl', `sincos', `stpcpy', `stpncpy', |
| `strcasecmp', `strdup', `strfmon', `strncasecmp', `strndup', `toascii', |
| `y0f', `y0l', `y0', `y1f', `y1l', `y1', `ynf', `ynl' and `yn' may be |
| handled as built-in functions. All these functions have corresponding |
| versions prefixed with `__builtin_', which may be used even in strict |
| C90 mode. |
| |
| The ISO C99 functions `_Exit', `acoshf', `acoshl', `acosh', `asinhf', |
| `asinhl', `asinh', `atanhf', `atanhl', `atanh', `cabsf', `cabsl', |
| `cabs', `cacosf', `cacoshf', `cacoshl', `cacosh', `cacosl', `cacos', |
| `cargf', `cargl', `carg', `casinf', `casinhf', `casinhl', `casinh', |
| `casinl', `casin', `catanf', `catanhf', `catanhl', `catanh', `catanl', |
| `catan', `cbrtf', `cbrtl', `cbrt', `ccosf', `ccoshf', `ccoshl', |
| `ccosh', `ccosl', `ccos', `cexpf', `cexpl', `cexp', `cimagf', `cimagl', |
| `cimag', `clogf', `clogl', `clog', `conjf', `conjl', `conj', |
| `copysignf', `copysignl', `copysign', `cpowf', `cpowl', `cpow', |
| `cprojf', `cprojl', `cproj', `crealf', `creall', `creal', `csinf', |
| `csinhf', `csinhl', `csinh', `csinl', `csin', `csqrtf', `csqrtl', |
| `csqrt', `ctanf', `ctanhf', `ctanhl', `ctanh', `ctanl', `ctan', |
| `erfcf', `erfcl', `erfc', `erff', `erfl', `erf', `exp2f', `exp2l', |
| `exp2', `expm1f', `expm1l', `expm1', `fdimf', `fdiml', `fdim', `fmaf', |
| `fmal', `fmaxf', `fmaxl', `fmax', `fma', `fminf', `fminl', `fmin', |
| `hypotf', `hypotl', `hypot', `ilogbf', `ilogbl', `ilogb', `imaxabs', |
| `isblank', `iswblank', `lgammaf', `lgammal', `lgamma', `llabs', |
| `llrintf', `llrintl', `llrint', `llroundf', `llroundl', `llround', |
| `log1pf', `log1pl', `log1p', `log2f', `log2l', `log2', `logbf', |
| `logbl', `logb', `lrintf', `lrintl', `lrint', `lroundf', `lroundl', |
| `lround', `nearbyintf', `nearbyintl', `nearbyint', `nextafterf', |
| `nextafterl', `nextafter', `nexttowardf', `nexttowardl', `nexttoward', |
| `remainderf', `remainderl', `remainder', `remquof', `remquol', |
| `remquo', `rintf', `rintl', `rint', `roundf', `roundl', `round', |
| `scalblnf', `scalblnl', `scalbln', `scalbnf', `scalbnl', `scalbn', |
| `snprintf', `tgammaf', `tgammal', `tgamma', `truncf', `truncl', `trunc', |
| `vfscanf', `vscanf', `vsnprintf' and `vsscanf' are handled as built-in |
| functions except in strict ISO C90 mode (`-ansi' or `-std=c90'). |
| |
| There are also built-in versions of the ISO C99 functions `acosf', |
| `acosl', `asinf', `asinl', `atan2f', `atan2l', `atanf', `atanl', |
| `ceilf', `ceill', `cosf', `coshf', `coshl', `cosl', `expf', `expl', |
| `fabsf', `fabsl', `floorf', `floorl', `fmodf', `fmodl', `frexpf', |
| `frexpl', `ldexpf', `ldexpl', `log10f', `log10l', `logf', `logl', |
| `modfl', `modf', `powf', `powl', `sinf', `sinhf', `sinhl', `sinl', |
| `sqrtf', `sqrtl', `tanf', `tanhf', `tanhl' and `tanl' that are |
| recognized in any mode since ISO C90 reserves these names for the |
| purpose to which ISO C99 puts them. All these functions have |
| corresponding versions prefixed with `__builtin_'. |
| |
| The ISO C94 functions `iswalnum', `iswalpha', `iswcntrl', `iswdigit', |
| `iswgraph', `iswlower', `iswprint', `iswpunct', `iswspace', `iswupper', |
| `iswxdigit', `towlower' and `towupper' are handled as built-in functions |
| except in strict ISO C90 mode (`-ansi' or `-std=c90'). |
| |
| The ISO C90 functions `abort', `abs', `acos', `asin', `atan2', `atan', |
| `calloc', `ceil', `cosh', `cos', `exit', `exp', `fabs', `floor', `fmod', |
| `fprintf', `fputs', `frexp', `fscanf', `isalnum', `isalpha', `iscntrl', |
| `isdigit', `isgraph', `islower', `isprint', `ispunct', `isspace', |
| `isupper', `isxdigit', `tolower', `toupper', `labs', `ldexp', `log10', |
| `log', `malloc', `memchr', `memcmp', `memcpy', `memset', `modf', `pow', |
| `printf', `putchar', `puts', `scanf', `sinh', `sin', `snprintf', |
| `sprintf', `sqrt', `sscanf', `strcat', `strchr', `strcmp', `strcpy', |
| `strcspn', `strlen', `strncat', `strncmp', `strncpy', `strpbrk', |
| `strrchr', `strspn', `strstr', `tanh', `tan', `vfprintf', `vprintf' and |
| `vsprintf' are all recognized as built-in functions unless |
| `-fno-builtin' is specified (or `-fno-builtin-FUNCTION' is specified |
| for an individual function). All of these functions have corresponding |
| versions prefixed with `__builtin_'. |
| |
| GCC provides built-in versions of the ISO C99 floating point comparison |
| macros that avoid raising exceptions for unordered operands. They have |
| the same names as the standard macros ( `isgreater', `isgreaterequal', |
| `isless', `islessequal', `islessgreater', and `isunordered') , with |
| `__builtin_' prefixed. We intend for a library implementor to be able |
| to simply `#define' each standard macro to its built-in equivalent. In |
| the same fashion, GCC provides `fpclassify', `isfinite', `isinf_sign' |
| and `isnormal' built-ins used with `__builtin_' prefixed. The `isinf' |
| and `isnan' 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 an |
| integer constant expression, is nonzero. Otherwise it returns |
| EXP2. |
| |
| This built-in function is analogous to the `? :' operator in C, |
| except that the expression returned has its type unaltered by |
| promotion rules. Also, the built-in function does not evaluate |
| the expression that 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, including the case where |
| `__builtin_constant_p' returns 1 because EXPRESSION can be folded |
| to a constant but EXPRESSION contains operands that would not |
| otherwise be permitted in a static initializer (for example, `0 && |
| foo ()'). GCC must be more conservative about evaluating the |
| built-in in this case, because it has no opportunity to perform |
| optimization. |
| |
| Previous versions of GCC did not accept this built-in in data |
| initializers. The earliest version where it is completely safe is |
| 3.0.1. |
| |
| -- Built-in Function: long __builtin_expect (long EXP, long C) |
| You may use `__builtin_expect' to provide the compiler with branch |
| prediction information. In general, you should prefer to use |
| actual profile feedback for this (`-fprofile-arcs'), as |
| programmers are notoriously bad at predicting how their programs |
| actually perform. However, there are applications in which this |
| data is hard to collect. |
| |
| The return value is the value of EXP, which should be an integral |
| expression. The semantics of the built-in are that it is expected |
| that EXP == C. For example: |
| |
| if (__builtin_expect (x, 0)) |
| foo (); |
| |
| 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_unreachable (void) |
| If control flow reaches the point of the `__builtin_unreachable', |
| the program is undefined. It is useful in situations where the |
| compiler cannot deduce the unreachability of the code. |
| |
| One such case is immediately following an `asm' statement that |
| will either never terminate, or one that transfers control |
| elsewhere and never returns. In this example, without the |
| `__builtin_unreachable', GCC would issue a warning that control |
| reaches the end of a non-void function. It would also generate |
| code to return after the `asm'. |
| |
| int f (int c, int v) |
| { |
| if (c) |
| { |
| return v; |
| } |
| else |
| { |
| asm("jmp error_handler"); |
| __builtin_unreachable (); |
| } |
| } |
| |
| Because the `asm' statement unconditionally transfers control out |
| of the function, control will never reach the end of the function |
| body. The `__builtin_unreachable' is in fact unreachable and |
| communicates this fact to the compiler. |
| |
| Another use for `__builtin_unreachable' is following a call a |
| function that never returns but that is not declared |
| `__attribute__((noreturn))', as in this example: |
| |
| void function_that_never_returns (void); |
| |
| int g (int c) |
| { |
| if (c) |
| { |
| return 1; |
| } |
| else |
| { |
| function_that_never_returns (); |
| __builtin_unreachable (); |
| } |
| } |
| |
| |
| -- Built-in Function: void __builtin___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. |
| |
| |
| File: gcc.info, Node: Target Builtins, Next: Target Format Checks, Prev: Other Builtins, Up: C Extensions |
| |
| 6.54 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/VSX Built-in Functions:: |
| * RX Built-in Functions:: |
| * SPARC VIS Built-in Functions:: |
| * SPU Built-in Functions:: |
| |
| |
| File: gcc.info, Node: Alpha Built-in Functions, Next: ARM iWMMXt Built-in Functions, Up: Target Builtins |
| |
| 6.54.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 *) |
| |
| |
| File: gcc.info, Node: ARM iWMMXt Built-in Functions, Next: ARM NEON Intrinsics, Prev: Alpha Built-in Functions, Up: Target Builtins |
| |
| 6.54.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 () |
| |
| |
| File: gcc.info, Node: ARM NEON Intrinsics, Next: Blackfin Built-in Functions, Prev: ARM iWMMXt Built-in Functions, Up: Target Builtins |
| |
| 6.54.3 ARM NEON Intrinsics |
| -------------------------- |
| |
| These built-in intrinsics for the ARM Advanced SIMD extension are |
| available when the `-mfpu=neon' switch is used: |
| |
| 6.54.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' |
| |
| * float32x2_t vadd_f32 (float32x2_t, float32x2_t) |
| _Form of expected instruction(s):_ `vadd.f32 D0, D0, D0' |
| |
| * uint64x1_t vadd_u64 (uint64x1_t, uint64x1_t) |
| |
| * int64x1_t vadd_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vaddq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vadd.i32 Q0, Q0, Q0' |
| |
| * uint16x8_t vaddq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vadd.i16 Q0, Q0, Q0' |
| |
| * uint8x16_t vaddq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vadd.i8 Q0, Q0, Q0' |
| |
| * int32x4_t vaddq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vadd.i32 Q0, Q0, Q0' |
| |
| * int16x8_t vaddq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vadd.i16 Q0, Q0, Q0' |
| |
| * int8x16_t vaddq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vadd.i8 Q0, Q0, Q0' |
| |
| * uint64x2_t vaddq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vadd.i64 Q0, Q0, Q0' |
| |
| * int64x2_t vaddq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vadd.i64 Q0, Q0, Q0' |
| |
| * float32x4_t vaddq_f32 (float32x4_t, float32x4_t) |
| _Form of expected instruction(s):_ `vadd.f32 Q0, Q0, Q0' |
| |
| * uint64x2_t vaddl_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vaddl.u32 Q0, D0, D0' |
| |
| * uint32x4_t vaddl_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vaddl.u16 Q0, D0, D0' |
| |
| * uint16x8_t vaddl_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vaddl.u8 Q0, D0, D0' |
| |
| * int64x2_t vaddl_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vaddl.s32 Q0, D0, D0' |
| |
| * int32x4_t vaddl_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vaddl.s16 Q0, D0, D0' |
| |
| * int16x8_t vaddl_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vaddl.s8 Q0, D0, D0' |
| |
| * uint64x2_t vaddw_u32 (uint64x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vaddw.u32 Q0, Q0, D0' |
| |
| * uint32x4_t vaddw_u16 (uint32x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vaddw.u16 Q0, Q0, D0' |
| |
| * uint16x8_t vaddw_u8 (uint16x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vaddw.u8 Q0, Q0, D0' |
| |
| * int64x2_t vaddw_s32 (int64x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vaddw.s32 Q0, Q0, D0' |
| |
| * int32x4_t vaddw_s16 (int32x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vaddw.s16 Q0, Q0, D0' |
| |
| * int16x8_t vaddw_s8 (int16x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vaddw.s8 Q0, Q0, D0' |
| |
| * uint32x2_t vhadd_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vhadd.u32 D0, D0, D0' |
| |
| * uint16x4_t vhadd_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vhadd.u16 D0, D0, D0' |
| |
| * uint8x8_t vhadd_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vhadd.u8 D0, D0, D0' |
| |
| * int32x2_t vhadd_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vhadd.s32 D0, D0, D0' |
| |
| * int16x4_t vhadd_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vhadd.s16 D0, D0, D0' |
| |
| * int8x8_t vhadd_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vhadd.s8 D0, D0, D0' |
| |
| * uint32x4_t vhaddq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vhadd.u32 Q0, Q0, Q0' |
| |
| * uint16x8_t vhaddq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vhadd.u16 Q0, Q0, Q0' |
| |
| * uint8x16_t vhaddq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vhadd.u8 Q0, Q0, Q0' |
| |
| * int32x4_t vhaddq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vhadd.s32 Q0, Q0, Q0' |
| |
| * int16x8_t vhaddq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vhadd.s16 Q0, Q0, Q0' |
| |
| * int8x16_t vhaddq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vhadd.s8 Q0, Q0, Q0' |
| |
| * uint32x2_t vrhadd_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vrhadd.u32 D0, D0, D0' |
| |
| * uint16x4_t vrhadd_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vrhadd.u16 D0, D0, D0' |
| |
| * uint8x8_t vrhadd_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vrhadd.u8 D0, D0, D0' |
| |
| * int32x2_t vrhadd_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vrhadd.s32 D0, D0, D0' |
| |
| * int16x4_t vrhadd_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vrhadd.s16 D0, D0, D0' |
| |
| * int8x8_t vrhadd_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vrhadd.s8 D0, D0, D0' |
| |
| * uint32x4_t vrhaddq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vrhadd.u32 Q0, Q0, Q0' |
| |
| * uint16x8_t vrhaddq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vrhadd.u16 Q0, Q0, Q0' |
| |
| * uint8x16_t vrhaddq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vrhadd.u8 Q0, Q0, Q0' |
| |
| * int32x4_t vrhaddq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vrhadd.s32 Q0, Q0, Q0' |
| |
| * int16x8_t vrhaddq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vrhadd.s16 Q0, Q0, Q0' |
| |
| * int8x16_t vrhaddq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vrhadd.s8 Q0, Q0, Q0' |
| |
| * uint32x2_t vqadd_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vqadd.u32 D0, D0, D0' |
| |
| * uint16x4_t vqadd_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vqadd.u16 D0, D0, D0' |
| |
| * uint8x8_t vqadd_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vqadd.u8 D0, D0, D0' |
| |
| * int32x2_t vqadd_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vqadd.s32 D0, D0, D0' |
| |
| * int16x4_t vqadd_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vqadd.s16 D0, D0, D0' |
| |
| * int8x8_t vqadd_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vqadd.s8 D0, D0, D0' |
| |
| * uint64x1_t vqadd_u64 (uint64x1_t, uint64x1_t) |
| _Form of expected instruction(s):_ `vqadd.u64 D0, D0, D0' |
| |
| * int64x1_t vqadd_s64 (int64x1_t, int64x1_t) |
| _Form of expected instruction(s):_ `vqadd.s64 D0, D0, D0' |
| |
| * uint32x4_t vqaddq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vqadd.u32 Q0, Q0, Q0' |
| |
| * uint16x8_t vqaddq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vqadd.u16 Q0, Q0, Q0' |
| |
| * uint8x16_t vqaddq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vqadd.u8 Q0, Q0, Q0' |
| |
| * int32x4_t vqaddq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vqadd.s32 Q0, Q0, Q0' |
| |
| * int16x8_t vqaddq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vqadd.s16 Q0, Q0, Q0' |
| |
| * int8x16_t vqaddq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vqadd.s8 Q0, Q0, Q0' |
| |
| * uint64x2_t vqaddq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vqadd.u64 Q0, Q0, Q0' |
| |
| * int64x2_t vqaddq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vqadd.s64 Q0, Q0, Q0' |
| |
| * uint32x2_t vaddhn_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vaddhn.i64 D0, Q0, Q0' |
| |
| * uint16x4_t vaddhn_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vaddhn.i32 D0, Q0, Q0' |
| |
| * uint8x8_t vaddhn_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vaddhn.i16 D0, Q0, Q0' |
| |
| * int32x2_t vaddhn_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vaddhn.i64 D0, Q0, Q0' |
| |
| * int16x4_t vaddhn_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vaddhn.i32 D0, Q0, Q0' |
| |
| * int8x8_t vaddhn_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vaddhn.i16 D0, Q0, Q0' |
| |
| * uint32x2_t vraddhn_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vraddhn.i64 D0, Q0, Q0' |
| |
| * uint16x4_t vraddhn_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vraddhn.i32 D0, Q0, Q0' |
| |
| * uint8x8_t vraddhn_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vraddhn.i16 D0, Q0, Q0' |
| |
| * int32x2_t vraddhn_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vraddhn.i64 D0, Q0, Q0' |
| |
| * int16x4_t vraddhn_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vraddhn.i32 D0, Q0, Q0' |
| |
| * int8x8_t vraddhn_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vraddhn.i16 D0, Q0, Q0' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| * float32x2_t vsub_f32 (float32x2_t, float32x2_t) |
| _Form of expected instruction(s):_ `vsub.f32 D0, D0, D0' |
| |
| * uint64x1_t vsub_u64 (uint64x1_t, uint64x1_t) |
| |
| * int64x1_t vsub_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vsubq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vsub.i32 Q0, Q0, Q0' |
| |
| * uint16x8_t vsubq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vsub.i16 Q0, Q0, Q0' |
| |
| * uint8x16_t vsubq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vsub.i8 Q0, Q0, Q0' |
| |
| * int32x4_t vsubq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vsub.i32 Q0, Q0, Q0' |
| |
| * int16x8_t vsubq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vsub.i16 Q0, Q0, Q0' |
| |
| * int8x16_t vsubq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vsub.i8 Q0, Q0, Q0' |
| |
| * uint64x2_t vsubq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vsub.i64 Q0, Q0, Q0' |
| |
| * int64x2_t vsubq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vsub.i64 Q0, Q0, Q0' |
| |
| * float32x4_t vsubq_f32 (float32x4_t, float32x4_t) |
| _Form of expected instruction(s):_ `vsub.f32 Q0, Q0, Q0' |
| |
| * uint64x2_t vsubl_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vsubl.u32 Q0, D0, D0' |
| |
| * uint32x4_t vsubl_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vsubl.u16 Q0, D0, D0' |
| |
| * uint16x8_t vsubl_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vsubl.u8 Q0, D0, D0' |
| |
| * int64x2_t vsubl_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vsubl.s32 Q0, D0, D0' |
| |
| * int32x4_t vsubl_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vsubl.s16 Q0, D0, D0' |
| |
| * int16x8_t vsubl_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vsubl.s8 Q0, D0, D0' |
| |
| * uint64x2_t vsubw_u32 (uint64x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vsubw.u32 Q0, Q0, D0' |
| |
| * uint32x4_t vsubw_u16 (uint32x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vsubw.u16 Q0, Q0, D0' |
| |
| * uint16x8_t vsubw_u8 (uint16x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vsubw.u8 Q0, Q0, D0' |
| |
| * int64x2_t vsubw_s32 (int64x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vsubw.s32 Q0, Q0, D0' |
| |
| * int32x4_t vsubw_s16 (int32x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vsubw.s16 Q0, Q0, D0' |
| |
| * int16x8_t vsubw_s8 (int16x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vsubw.s8 Q0, Q0, D0' |
| |
| * uint32x2_t vhsub_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vhsub.u32 D0, D0, D0' |
| |
| * uint16x4_t vhsub_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vhsub.u16 D0, D0, D0' |
| |
| * uint8x8_t vhsub_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vhsub.u8 D0, D0, D0' |
| |
| * int32x2_t vhsub_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vhsub.s32 D0, D0, D0' |
| |
| * int16x4_t vhsub_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vhsub.s16 D0, D0, D0' |
| |
| * int8x8_t vhsub_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vhsub.s8 D0, D0, D0' |
| |
| * uint32x4_t vhsubq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vhsub.u32 Q0, Q0, Q0' |
| |
| * uint16x8_t vhsubq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vhsub.u16 Q0, Q0, Q0' |
| |
| * uint8x16_t vhsubq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vhsub.u8 Q0, Q0, Q0' |
| |
| * int32x4_t vhsubq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vhsub.s32 Q0, Q0, Q0' |
| |
| * int16x8_t vhsubq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vhsub.s16 Q0, Q0, Q0' |
| |
| * int8x16_t vhsubq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vhsub.s8 Q0, Q0, Q0' |
| |
| * uint32x2_t vqsub_u32 (uint32x2_t, uint32x2_t) |
| _Form of expected instruction(s):_ `vqsub.u32 D0, D0, D0' |
| |
| * uint16x4_t vqsub_u16 (uint16x4_t, uint16x4_t) |
| _Form of expected instruction(s):_ `vqsub.u16 D0, D0, D0' |
| |
| * uint8x8_t vqsub_u8 (uint8x8_t, uint8x8_t) |
| _Form of expected instruction(s):_ `vqsub.u8 D0, D0, D0' |
| |
| * int32x2_t vqsub_s32 (int32x2_t, int32x2_t) |
| _Form of expected instruction(s):_ `vqsub.s32 D0, D0, D0' |
| |
| * int16x4_t vqsub_s16 (int16x4_t, int16x4_t) |
| _Form of expected instruction(s):_ `vqsub.s16 D0, D0, D0' |
| |
| * int8x8_t vqsub_s8 (int8x8_t, int8x8_t) |
| _Form of expected instruction(s):_ `vqsub.s8 D0, D0, D0' |
| |
| * uint64x1_t vqsub_u64 (uint64x1_t, uint64x1_t) |
| _Form of expected instruction(s):_ `vqsub.u64 D0, D0, D0' |
| |
| * int64x1_t vqsub_s64 (int64x1_t, int64x1_t) |
| _Form of expected instruction(s):_ `vqsub.s64 D0, D0, D0' |
| |
| * uint32x4_t vqsubq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vqsub.u32 Q0, Q0, Q0' |
| |
| * uint16x8_t vqsubq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vqsub.u16 Q0, Q0, Q0' |
| |
| * uint8x16_t vqsubq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vqsub.u8 Q0, Q0, Q0' |
| |
| * int32x4_t vqsubq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vqsub.s32 Q0, Q0, Q0' |
| |
| * int16x8_t vqsubq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vqsub.s16 Q0, Q0, Q0' |
| |
| * int8x16_t vqsubq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vqsub.s8 Q0, Q0, Q0' |
| |
| * uint64x2_t vqsubq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vqsub.u64 Q0, Q0, Q0' |
| |
| * int64x2_t vqsubq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vqsub.s64 Q0, Q0, Q0' |
| |
| * uint32x2_t vsubhn_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vsubhn.i64 D0, Q0, Q0' |
| |
| * uint16x4_t vsubhn_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vsubhn.i32 D0, Q0, Q0' |
| |
| * uint8x8_t vsubhn_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vsubhn.i16 D0, Q0, Q0' |
| |
| * int32x2_t vsubhn_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vsubhn.i64 D0, Q0, Q0' |
| |
| * int16x4_t vsubhn_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vsubhn.i32 D0, Q0, Q0' |
| |
| * int8x8_t vsubhn_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vsubhn.i16 D0, Q0, Q0' |
| |
| * uint32x2_t vrsubhn_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vrsubhn.i64 D0, Q0, Q0' |
| |
| * uint16x4_t vrsubhn_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vrsubhn.i32 D0, Q0, Q0' |
| |
| * uint8x8_t vrsubhn_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vrsubhn.i16 D0, Q0, Q0' |
| |
| * int32x2_t vrsubhn_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vrsubhn.i64 D0, Q0, Q0' |
| |
| * int16x4_t vrsubhn_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vrsubhn.i32 D0, Q0, Q0' |
| |
| * int8x8_t vrsubhn_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vrsubhn.i16 D0, Q0, Q0' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.3.39 Get lanes from a vector |
| ................................. |
| |
| * uint32_t vget_lane_u32 (uint32x2_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * uint16_t vget_lane_u16 (uint16x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]' |
| |
| * uint8_t vget_lane_u8 (uint8x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]' |
| |
| * int32_t vget_lane_s32 (int32x2_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * int16_t vget_lane_s16 (int16x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.s16 R0, D0[0]' |
| |
| * int8_t vget_lane_s8 (int8x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.s8 R0, D0[0]' |
| |
| * float32_t vget_lane_f32 (float32x2_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * poly16_t vget_lane_p16 (poly16x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]' |
| |
| * poly8_t vget_lane_p8 (poly8x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]' |
| |
| * uint64_t vget_lane_u64 (uint64x1_t, const int) |
| |
| * int64_t vget_lane_s64 (int64x1_t, const int) |
| |
| * uint32_t vgetq_lane_u32 (uint32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * uint16_t vgetq_lane_u16 (uint16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]' |
| |
| * uint8_t vgetq_lane_u8 (uint8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]' |
| |
| * int32_t vgetq_lane_s32 (int32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * int16_t vgetq_lane_s16 (int16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.s16 R0, D0[0]' |
| |
| * int8_t vgetq_lane_s8 (int8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.s8 R0, D0[0]' |
| |
| * float32_t vgetq_lane_f32 (float32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 R0, D0[0]' |
| |
| * poly16_t vgetq_lane_p16 (poly16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]' |
| |
| * poly8_t vgetq_lane_p8 (poly8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]' |
| |
| * uint64_t vgetq_lane_u64 (uint64x2_t, const int) |
| _Form of expected instruction(s):_ `vmov R0, R0, D0' |
| |
| * int64_t vgetq_lane_s64 (int64x2_t, const int) |
| _Form of expected instruction(s):_ `vmov R0, R0, D0' |
| |
| 6.54.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) |
| |
| * int64x1_t vset_lane_s64 (int64_t, int64x1_t, const int) |
| |
| * uint32x4_t vsetq_lane_u32 (uint32_t, uint32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 D0[0], R0' |
| |
| * uint16x8_t vsetq_lane_u16 (uint16_t, uint16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.16 D0[0], R0' |
| |
| * uint8x16_t vsetq_lane_u8 (uint8_t, uint8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.8 D0[0], R0' |
| |
| * int32x4_t vsetq_lane_s32 (int32_t, int32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 D0[0], R0' |
| |
| * int16x8_t vsetq_lane_s16 (int16_t, int16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.16 D0[0], R0' |
| |
| * int8x16_t vsetq_lane_s8 (int8_t, int8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.8 D0[0], R0' |
| |
| * float32x4_t vsetq_lane_f32 (float32_t, float32x4_t, const int) |
| _Form of expected instruction(s):_ `vmov.32 D0[0], R0' |
| |
| * poly16x8_t vsetq_lane_p16 (poly16_t, poly16x8_t, const int) |
| _Form of expected instruction(s):_ `vmov.16 D0[0], R0' |
| |
| * poly8x16_t vsetq_lane_p8 (poly8_t, poly8x16_t, const int) |
| _Form of expected instruction(s):_ `vmov.8 D0[0], R0' |
| |
| * uint64x2_t vsetq_lane_u64 (uint64_t, uint64x2_t, const int) |
| _Form of expected instruction(s):_ `vmov D0, R0, R0' |
| |
| * int64x2_t vsetq_lane_s64 (int64_t, int64x2_t, const int) |
| _Form of expected instruction(s):_ `vmov D0, R0, R0' |
| |
| 6.54.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) |
| |
| 6.54.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) |
| |
| * int64x1_t vdup_n_s64 (int64_t) |
| |
| * uint32x4_t vdupq_n_u32 (uint32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * uint16x8_t vdupq_n_u16 (uint16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * uint8x16_t vdupq_n_u8 (uint8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * int32x4_t vdupq_n_s32 (int32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * int16x8_t vdupq_n_s16 (int16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * int8x16_t vdupq_n_s8 (int8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * float32x4_t vdupq_n_f32 (float32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * poly16x8_t vdupq_n_p16 (poly16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * poly8x16_t vdupq_n_p8 (poly8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * uint64x2_t vdupq_n_u64 (uint64_t) |
| |
| * int64x2_t vdupq_n_s64 (int64_t) |
| |
| * uint32x2_t vmov_n_u32 (uint32_t) |
| _Form of expected instruction(s):_ `vdup.32 D0, R0' |
| |
| * uint16x4_t vmov_n_u16 (uint16_t) |
| _Form of expected instruction(s):_ `vdup.16 D0, R0' |
| |
| * uint8x8_t vmov_n_u8 (uint8_t) |
| _Form of expected instruction(s):_ `vdup.8 D0, R0' |
| |
| * int32x2_t vmov_n_s32 (int32_t) |
| _Form of expected instruction(s):_ `vdup.32 D0, R0' |
| |
| * int16x4_t vmov_n_s16 (int16_t) |
| _Form of expected instruction(s):_ `vdup.16 D0, R0' |
| |
| * int8x8_t vmov_n_s8 (int8_t) |
| _Form of expected instruction(s):_ `vdup.8 D0, R0' |
| |
| * float32x2_t vmov_n_f32 (float32_t) |
| _Form of expected instruction(s):_ `vdup.32 D0, R0' |
| |
| * poly16x4_t vmov_n_p16 (poly16_t) |
| _Form of expected instruction(s):_ `vdup.16 D0, R0' |
| |
| * poly8x8_t vmov_n_p8 (poly8_t) |
| _Form of expected instruction(s):_ `vdup.8 D0, R0' |
| |
| * uint64x1_t vmov_n_u64 (uint64_t) |
| |
| * int64x1_t vmov_n_s64 (int64_t) |
| |
| * uint32x4_t vmovq_n_u32 (uint32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * uint16x8_t vmovq_n_u16 (uint16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * uint8x16_t vmovq_n_u8 (uint8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * int32x4_t vmovq_n_s32 (int32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * int16x8_t vmovq_n_s16 (int16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * int8x16_t vmovq_n_s8 (int8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * float32x4_t vmovq_n_f32 (float32_t) |
| _Form of expected instruction(s):_ `vdup.32 Q0, R0' |
| |
| * poly16x8_t vmovq_n_p16 (poly16_t) |
| _Form of expected instruction(s):_ `vdup.16 Q0, R0' |
| |
| * poly8x16_t vmovq_n_p8 (poly8_t) |
| _Form of expected instruction(s):_ `vdup.8 Q0, R0' |
| |
| * uint64x2_t vmovq_n_u64 (uint64_t) |
| |
| * int64x2_t vmovq_n_s64 (int64_t) |
| |
| * uint32x2_t vdup_lane_u32 (uint32x2_t, const int) |
| _Form of expected instruction(s):_ `vdup.32 D0, D0[0]' |
| |
| * uint16x4_t vdup_lane_u16 (uint16x4_t, const int) |
| _Form of expected instruction(s):_ `vdup.16 D0, D0[0]' |
| |
| * uint8x8_t vdup_lane_u8 (uint8x8_t, const int) |
| _Form of expected instruction(s):_ `vdup.8 D0, D0[0]' |
| |
| * int32x2_t vdup_lane_s32 (int32x2_t, const int) |
| _Form of expected instruction(s):_ `vdup.32 D0, D0[0]' |
| |
| * int16x4_t vdup_lane_s16 (int16x4_t, const int) |
| _Form of expected instruction(s):_ `vdup.16 D0, D0[0]' |
| |
| * int8x8_t vdup_lane_s8 (int8x8_t, const int) |
| _Form of expected instruction(s):_ `vdup.8 D0, D0[0]' |
| |
| * float32x2_t vdup_lane_f32 (float32x2_t, const int) |
| _Form of expected instruction(s):_ `vdup.32 D0, D0[0]' |
| |
| * poly16x4_t vdup_lane_p16 (poly16x4_t, const int) |
| _Form of expected instruction(s):_ `vdup.16 D0, D0[0]' |
| |
| * poly8x8_t vdup_lane_p8 (poly8x8_t, const int) |
| _Form of expected instruction(s):_ `vdup.8 D0, D0[0]' |
| |
| * 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) |
| |
| 6.54.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) |
| |
| 6.54.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' |
| |
| * 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' |
| |
| * uint64x1_t vget_low_u64 (uint64x2_t) |
| |
| * int64x1_t vget_low_s64 (int64x2_t) |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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]' |
| |
| 6.54.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) |
| |
| * int64x1_t vand_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vandq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * uint16x8_t vandq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * uint8x16_t vandq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * int32x4_t vandq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * int16x8_t vandq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * int8x16_t vandq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * uint64x2_t vandq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| * int64x2_t vandq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vand Q0, Q0, Q0' |
| |
| 6.54.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) |
| |
| * int64x1_t vorr_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vorrq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * uint16x8_t vorrq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * uint8x16_t vorrq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * int32x4_t vorrq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * int16x8_t vorrq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * int8x16_t vorrq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * uint64x2_t vorrq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| * int64x2_t vorrq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vorr Q0, Q0, Q0' |
| |
| 6.54.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) |
| |
| * int64x1_t veor_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t veorq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * uint16x8_t veorq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * uint8x16_t veorq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * int32x4_t veorq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * int16x8_t veorq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * int8x16_t veorq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * uint64x2_t veorq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| * int64x2_t veorq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `veor Q0, Q0, Q0' |
| |
| 6.54.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) |
| |
| * int64x1_t vbic_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vbicq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * uint16x8_t vbicq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * uint8x16_t vbicq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * int32x4_t vbicq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * int16x8_t vbicq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * int8x16_t vbicq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * uint64x2_t vbicq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| * int64x2_t vbicq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vbic Q0, Q0, Q0' |
| |
| 6.54.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) |
| |
| * int64x1_t vorn_s64 (int64x1_t, int64x1_t) |
| |
| * uint32x4_t vornq_u32 (uint32x4_t, uint32x4_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * uint16x8_t vornq_u16 (uint16x8_t, uint16x8_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * uint8x16_t vornq_u8 (uint8x16_t, uint8x16_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * int32x4_t vornq_s32 (int32x4_t, int32x4_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * int16x8_t vornq_s16 (int16x8_t, int16x8_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * int8x16_t vornq_s8 (int8x16_t, int8x16_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * uint64x2_t vornq_u64 (uint64x2_t, uint64x2_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| * int64x2_t vornq_s64 (int64x2_t, int64x2_t) |
| _Form of expected instruction(s):_ `vorn Q0, Q0, Q0' |
| |
| 6.54.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) |
| |
| |
| File: gcc.info, Node: Blackfin Built-in Functions, Next: FR-V Built-in Functions, Prev: ARM NEON Intrinsics, Up: Target Builtins |
| |
| 6.54.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) |
| |
| |
| File: gcc.info, Node: FR-V Built-in Functions, Next: X86 Built-in Functions, Prev: Blackfin Built-in Functions, Up: Target Builtins |
| |
| 6.54.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:: |
| |
| |
| File: gcc.info, Node: Argument Types, Next: Directly-mapped Integer Functions, Up: FR-V Built-in Functions |
| |
| 6.54.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. |
| |
| |
| File: gcc.info, Node: Directly-mapped Integer Functions, Next: Directly-mapped Media Functions, Prev: Argument Types, Up: FR-V Built-in Functions |
| |
| 6.54.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' |
| |
| |
| File: gcc.info, Node: Directly-mapped Media Functions, Next: Raw read/write Functions, Prev: Directly-mapped Integer Functions, Up: FR-V Built-in Functions |
| |
| 6.54.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' |
| |
| |
| File: gcc.info, Node: Raw read/write Functions, Next: Other Built-in Functions, Prev: Directly-mapped Media Functions, Up: FR-V Built-in Functions |
| |
| 6.54.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)' |
| |
| |
| File: gcc.info, Node: Other Built-in Functions, Prev: Raw read/write Functions, Up: FR-V Built-in Functions |
| |
| 6.54.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. |
| |
| |
| File: gcc.info, Node: X86 Built-in Functions, Next: MIPS DSP Built-in Functions, Prev: FR-V Built-in Functions, Up: Target Builtins |
| |
| 6.54.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'. |
| |
| `__float128 __builtin_huge_valq (void)' |
| Similar to `__builtin_huge_val', 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 function is available when `-mfsgsbase' is |
| used. All of them generate the machine instruction that is part of the |
| name. |
| |
| unsigned int __builtin_ia32_rdfsbase32 (void) |
| unsigned long long __builtin_ia32_rdfsbase64 (void) |
| unsigned int __builtin_ia32_rdgsbase32 (void) |
| unsigned long long __builtin_ia32_rdgsbase64 (void) |
| void _writefsbase_u32 (unsigned int) |
| void _writefsbase_u64 (unsigned long long) |
| void _writegsbase_u32 (unsigned int) |
| void _writegsbase_u64 (unsigned long long) |
| |
| The following built-in function is available when `-mrdrnd' is used. |
| All of them generate the machine instruction that is part of the name. |
| |
| unsigned int __builtin_ia32_rdrand16_step (unsigned short *) |
| unsigned int __builtin_ia32_rdrand32_step (unsigned int *) |
| unsigned int __builtin_ia32_rdrand64_step (unsigned long long *) |
| |
| The following built-in functions are available when `-msse4a' is used. |
| All of them generate the machine instruction that is part of the name. |
| |
| void __builtin_ia32_movntsd (double *, v2df) |
| void __builtin_ia32_movntss (float *, v4sf) |
| v2di __builtin_ia32_extrq (v2di, v16qi) |
| v2di __builtin_ia32_extrqi (v2di, const unsigned int, const unsigned int) |
| v2di __builtin_ia32_insertq (v2di, v2di) |
| v2di __builtin_ia32_insertqi (v2di, v2di, const unsigned int, const unsigned int) |
| |
| The following built-in functions are available when `-mxop' is used. |
| v2df __builtin_ia32_vfrczpd (v2df) |
| v4sf __builtin_ia32_vfrczps (v4sf) |
| v2df __builtin_ia32_vfrczsd (v2df, v2df) |
| v4sf __builtin_ia32_vfrczss (v4sf, v4sf) |
| v4df __builtin_ia32_vfrczpd256 (v4df) |
| v8sf __builtin_ia32_vfrczps256 (v8sf) |
| v2di __builtin_ia32_vpcmov (v2di, v2di, v2di) |
| v2di __builtin_ia32_vpcmov_v2di (v2di, v2di, v2di) |
| v4si __builtin_ia32_vpcmov_v4si (v4si, v4si, v4si) |
| v8hi __builtin_ia32_vpcmov_v8hi (v8hi, v8hi, v8hi) |
| v16qi __builtin_ia32_vpcmov_v16qi (v16qi, v16qi, v16qi) |
| v2df __builtin_ia32_vpcmov_v2df (v2df, v2df, v2df) |
| v4sf __builtin_ia32_vpcmov_v4sf (v4sf, v4sf, v4sf) |
| v4di __builtin_ia32_vpcmov_v4di256 (v4di, v4di, v4di) |
| v8si __builtin_ia32_vpcmov_v8si256 (v8si, v8si, v8si) |
| v16hi __builtin_ia32_vpcmov_v16hi256 (v16hi, v16hi, v16hi) |
| v32qi __builtin_ia32_vpcmov_v32qi256 (v32qi, v32qi, v32qi) |
| v4df __builtin_ia32_vpcmov_v4df256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_vpcmov_v8sf256 (v8sf, v8sf, v8sf) |
| v16qi __builtin_ia32_vpcomeqb (v16qi, v16qi) |
| v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi) |
| v4si __builtin_ia32_vpcomeqd (v4si, v4si) |
| v2di __builtin_ia32_vpcomeqq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomequb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomequd (v4si, v4si) |
| v2di __builtin_ia32_vpcomequq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomequw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomfalseb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomfalsed (v4si, v4si) |
| v2di __builtin_ia32_vpcomfalseq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomfalseub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomfalseud (v4si, v4si) |
| v2di __builtin_ia32_vpcomfalseuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomfalseuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomfalsew (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomgeb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomged (v4si, v4si) |
| v2di __builtin_ia32_vpcomgeq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomgeub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomgeud (v4si, v4si) |
| v2di __builtin_ia32_vpcomgeuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomgeuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomgew (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomgtb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomgtd (v4si, v4si) |
| v2di __builtin_ia32_vpcomgtq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomgtub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomgtud (v4si, v4si) |
| v2di __builtin_ia32_vpcomgtuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomgtuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomgtw (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomleb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomled (v4si, v4si) |
| v2di __builtin_ia32_vpcomleq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomleub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomleud (v4si, v4si) |
| v2di __builtin_ia32_vpcomleuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomleuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomlew (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomltb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomltd (v4si, v4si) |
| v2di __builtin_ia32_vpcomltq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomltub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomltud (v4si, v4si) |
| v2di __builtin_ia32_vpcomltuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomltuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomltw (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomneb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomned (v4si, v4si) |
| v2di __builtin_ia32_vpcomneq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomneub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomneud (v4si, v4si) |
| v2di __builtin_ia32_vpcomneuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomneuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomnew (v8hi, v8hi) |
| v16qi __builtin_ia32_vpcomtrueb (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomtrued (v4si, v4si) |
| v2di __builtin_ia32_vpcomtrueq (v2di, v2di) |
| v16qi __builtin_ia32_vpcomtrueub (v16qi, v16qi) |
| v4si __builtin_ia32_vpcomtrueud (v4si, v4si) |
| v2di __builtin_ia32_vpcomtrueuq (v2di, v2di) |
| v8hi __builtin_ia32_vpcomtrueuw (v8hi, v8hi) |
| v8hi __builtin_ia32_vpcomtruew (v8hi, v8hi) |
| v4si __builtin_ia32_vphaddbd (v16qi) |
| v2di __builtin_ia32_vphaddbq (v16qi) |
| v8hi __builtin_ia32_vphaddbw (v16qi) |
| v2di __builtin_ia32_vphadddq (v4si) |
| v4si __builtin_ia32_vphaddubd (v16qi) |
| v2di __builtin_ia32_vphaddubq (v16qi) |
| v8hi __builtin_ia32_vphaddubw (v16qi) |
| v2di __builtin_ia32_vphaddudq (v4si) |
| v4si __builtin_ia32_vphadduwd (v8hi) |
| v2di __builtin_ia32_vphadduwq (v8hi) |
| v4si __builtin_ia32_vphaddwd (v8hi) |
| v2di __builtin_ia32_vphaddwq (v8hi) |
| v8hi __builtin_ia32_vphsubbw (v16qi) |
| v2di __builtin_ia32_vphsubdq (v4si) |
| v4si __builtin_ia32_vphsubwd (v8hi) |
| v4si __builtin_ia32_vpmacsdd (v4si, v4si, v4si) |
| v2di __builtin_ia32_vpmacsdqh (v4si, v4si, v2di) |
| v2di __builtin_ia32_vpmacsdql (v4si, v4si, v2di) |
| v4si __builtin_ia32_vpmacssdd (v4si, v4si, v4si) |
| v2di __builtin_ia32_vpmacssdqh (v4si, v4si, v2di) |
| v2di __builtin_ia32_vpmacssdql (v4si, v4si, v2di) |
| v4si __builtin_ia32_vpmacsswd (v8hi, v8hi, v4si) |
| v8hi __builtin_ia32_vpmacssww (v8hi, v8hi, v8hi) |
| v4si __builtin_ia32_vpmacswd (v8hi, v8hi, v4si) |
| v8hi __builtin_ia32_vpmacsww (v8hi, v8hi, v8hi) |
| v4si __builtin_ia32_vpmadcsswd (v8hi, v8hi, v4si) |
| v4si __builtin_ia32_vpmadcswd (v8hi, v8hi, v4si) |
| v16qi __builtin_ia32_vpperm (v16qi, v16qi, v16qi) |
| v16qi __builtin_ia32_vprotb (v16qi, v16qi) |
| v4si __builtin_ia32_vprotd (v4si, v4si) |
| v2di __builtin_ia32_vprotq (v2di, v2di) |
| v8hi __builtin_ia32_vprotw (v8hi, v8hi) |
| v16qi __builtin_ia32_vpshab (v16qi, v16qi) |
| v4si __builtin_ia32_vpshad (v4si, v4si) |
| v2di __builtin_ia32_vpshaq (v2di, v2di) |
| v8hi __builtin_ia32_vpshaw (v8hi, v8hi) |
| v16qi __builtin_ia32_vpshlb (v16qi, v16qi) |
| v4si __builtin_ia32_vpshld (v4si, v4si) |
| v2di __builtin_ia32_vpshlq (v2di, v2di) |
| v8hi __builtin_ia32_vpshlw (v8hi, v8hi) |
| |
| The following built-in functions are available when `-mfma4' is used. |
| All of them generate the machine instruction that is part of the name |
| with MMX registers. |
| |
| 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_fmaddsubpd (v2df, v2df, v2df) |
| v4sf __builtin_ia32_fmaddsubps (v4sf, v4sf, v4sf) |
| v2df __builtin_ia32_fmsubaddpd (v2df, v2df, v2df) |
| v4sf __builtin_ia32_fmsubaddps (v4sf, v4sf, v4sf) |
| v4df __builtin_ia32_fmaddpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fmaddps256 (v8sf, v8sf, v8sf) |
| v4df __builtin_ia32_fmsubpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fmsubps256 (v8sf, v8sf, v8sf) |
| v4df __builtin_ia32_fnmaddpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fnmaddps256 (v8sf, v8sf, v8sf) |
| v4df __builtin_ia32_fnmsubpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fnmsubps256 (v8sf, v8sf, v8sf) |
| v4df __builtin_ia32_fmaddsubpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fmaddsubps256 (v8sf, v8sf, v8sf) |
| v4df __builtin_ia32_fmsubaddpd256 (v4df, v4df, v4df) |
| v8sf __builtin_ia32_fmsubaddps256 (v8sf, v8sf, v8sf) |
| |
| The following built-in functions are available when `-mlwp' is used. |
| |
| void __builtin_ia32_llwpcb16 (void *); |
| void __builtin_ia32_llwpcb32 (void *); |
| void __builtin_ia32_llwpcb64 (void *); |
| void * __builtin_ia32_llwpcb16 (void); |
| void * __builtin_ia32_llwpcb32 (void); |
| void * __builtin_ia32_llwpcb64 (void); |
| void __builtin_ia32_lwpval16 (unsigned short, unsigned int, unsigned short) |
| void __builtin_ia32_lwpval32 (unsigned int, unsigned int, unsigned int) |
| void __builtin_ia32_lwpval64 (unsigned __int64, unsigned int, unsigned int) |
| unsigned char __builtin_ia32_lwpins16 (unsigned short, unsigned int, unsigned short) |
| unsigned char __builtin_ia32_lwpins32 (unsigned int, unsigned int, unsigned int) |
| unsigned char __builtin_ia32_lwpins64 (unsigned __int64, unsigned int, unsigned int) |
| |
| The following built-in functions are available when `-mbmi' is used. |
| All of them generate the machine instruction that is part of the name. |
| unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int); |
| unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long); |
| unsigned short __builtin_ia32_lzcnt_16(unsigned short); |
| unsigned int __builtin_ia32_lzcnt_u32(unsigned int); |
| unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long); |
| |
| The following built-in functions are available when `-mtbm' is used. |
| Both of them generate the immediate form of the bextr machine |
| instruction. |
| unsigned int __builtin_ia32_bextri_u32 (unsigned int, const unsigned int); |
| unsigned long long __builtin_ia32_bextri_u64 (unsigned long long, const unsigned long long); |
| |
| The following built-in functions are available when `-m3dnow' is used. |
| All of them generate the machine instruction that is part of the name. |
| |
| void __builtin_ia32_femms (void) |
| v8qi __builtin_ia32_pavgusb (v8qi, v8qi) |
| v2si __builtin_ia32_pf2id (v2sf) |
| v2sf __builtin_ia32_pfacc (v2sf, v2sf) |
| v2sf __builtin_ia32_pfadd (v2sf, v2sf) |
| v2si __builtin_ia32_pfcmpeq (v2sf, v2sf) |
| v2si __builtin_ia32_pfcmpge (v2sf, v2sf) |
| v2si __builtin_ia32_pfcmpgt (v2sf, v2sf) |
| v2sf __builtin_ia32_pfmax (v2sf, v2sf) |
| v2sf __builtin_ia32_pfmin (v2sf, v2sf) |
| v2sf __builtin_ia32_pfmul (v2sf, v2sf) |
| v2sf __builtin_ia32_pfrcp (v2sf) |
| v2sf __builtin_ia32_pfrcpit1 (v2sf, v2sf) |
| v2sf __builtin_ia32_pfrcpit2 (v2sf, v2sf) |
| v2sf __builtin_ia32_pfrsqrt (v2sf) |
| v2sf __builtin_ia32_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) |
| |
| |
| File: gcc.info, Node: MIPS DSP Built-in Functions, Next: MIPS Paired-Single Support, Prev: X86 Built-in Functions, Up: Target Builtins |
| |
| 6.54.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) |
| a64 __builtin_mips_madd (a64, i32, i32); |
| a64 __builtin_mips_maddu (a64, ui32, ui32); |
| a64 __builtin_mips_msub (a64, i32, i32); |
| a64 __builtin_mips_msubu (a64, ui32, ui32); |
| a64 __builtin_mips_mult (i32, i32); |
| a64 __builtin_mips_multu (ui32, ui32); |
| |
| The following built-in functions map directly to a particular MIPS DSP |
| REV 2 instruction. Please refer to the architecture specification for |
| details on what each instruction does. |
| |
| v4q7 __builtin_mips_absq_s_qb (v4q7); |
| v2i16 __builtin_mips_addu_ph (v2i16, v2i16); |
| v2i16 __builtin_mips_addu_s_ph (v2i16, v2i16); |
| v4i8 __builtin_mips_adduh_qb (v4i8, v4i8); |
| v4i8 __builtin_mips_adduh_r_qb (v4i8, v4i8); |
| i32 __builtin_mips_append (i32, i32, imm0_31); |
| i32 __builtin_mips_balign (i32, i32, imm0_3); |
| i32 __builtin_mips_cmpgdu_eq_qb (v4i8, v4i8); |
| i32 __builtin_mips_cmpgdu_lt_qb (v4i8, v4i8); |
| i32 __builtin_mips_cmpgdu_le_qb (v4i8, v4i8); |
| a64 __builtin_mips_dpa_w_ph (a64, v2i16, v2i16); |
| a64 __builtin_mips_dps_w_ph (a64, v2i16, v2i16); |
| v2i16 __builtin_mips_mul_ph (v2i16, v2i16); |
| v2i16 __builtin_mips_mul_s_ph (v2i16, v2i16); |
| q31 __builtin_mips_mulq_rs_w (q31, q31); |
| v2q15 __builtin_mips_mulq_s_ph (v2q15, v2q15); |
| q31 __builtin_mips_mulq_s_w (q31, q31); |
| a64 __builtin_mips_mulsa_w_ph (a64, v2i16, v2i16); |
| v4i8 __builtin_mips_precr_qb_ph (v2i16, v2i16); |
| v2i16 __builtin_mips_precr_sra_ph_w (i32, i32, imm0_31); |
| v2i16 __builtin_mips_precr_sra_r_ph_w (i32, i32, imm0_31); |
| i32 __builtin_mips_prepend (i32, i32, imm0_31); |
| v4i8 __builtin_mips_shra_qb (v4i8, imm0_7); |
| v4i8 __builtin_mips_shra_r_qb (v4i8, imm0_7); |
| v4i8 __builtin_mips_shra_qb (v4i8, i32); |
| v4i8 __builtin_mips_shra_r_qb (v4i8, i32); |
| v2i16 __builtin_mips_shrl_ph (v2i16, imm0_15); |
| v2i16 __builtin_mips_shrl_ph (v2i16, i32); |
| v2i16 __builtin_mips_subu_ph (v2i16, v2i16); |
| v2i16 __builtin_mips_subu_s_ph (v2i16, v2i16); |
| v4i8 __builtin_mips_subuh_qb (v4i8, v4i8); |
| v4i8 __builtin_mips_subuh_r_qb (v4i8, v4i8); |
| v2q15 __builtin_mips_addqh_ph (v2q15, v2q15); |
| v2q15 __builtin_mips_addqh_r_ph (v2q15, v2q15); |
| q31 __builtin_mips_addqh_w (q31, q31); |
| q31 __builtin_mips_addqh_r_w (q31, q31); |
| v2q15 __builtin_mips_subqh_ph (v2q15, v2q15); |
| v2q15 __builtin_mips_subqh_r_ph (v2q15, v2q15); |
| q31 __builtin_mips_subqh_w (q31, q31); |
| q31 __builtin_mips_subqh_r_w (q31, q31); |
| a64 __builtin_mips_dpax_w_ph (a64, v2i16, v2i16); |
| a64 __builtin_mips_dpsx_w_ph (a64, v2i16, v2i16); |
| a64 __builtin_mips_dpaqx_s_w_ph (a64, v2q15, v2q15); |
| a64 __builtin_mips_dpaqx_sa_w_ph (a64, v2q15, v2q15); |
| a64 __builtin_mips_dpsqx_s_w_ph (a64, v2q15, v2q15); |
| a64 __builtin_mips_dpsqx_sa_w_ph (a64, v2q15, v2q15); |
| |
| |
| File: gcc.info, Node: MIPS Paired-Single Support, Next: MIPS Loongson Built-in Functions, Prev: MIPS DSP Built-in Functions, Up: Target Builtins |
| |
| 6.54.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. |
| |
| |
| File: gcc.info, Node: MIPS Loongson Built-in Functions, Next: Other MIPS Built-in Functions, Prev: MIPS Paired-Single Support, Up: Target Builtins |
| |
| 6.54.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:: |
| |
| |
| File: gcc.info, Node: Paired-Single Arithmetic, Next: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions |
| |
| 6.54.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'. |
| |
| |
| File: gcc.info, Node: Paired-Single Built-in Functions, Next: MIPS-3D Built-in Functions, Prev: Paired-Single Arithmetic, Up: MIPS Loongson Built-in Functions |
| |
| 6.54.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 (); |
| |
| |
| File: gcc.info, Node: MIPS-3D Built-in Functions, Prev: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions |
| |
| 6.54.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 (); |
| |
| |
| File: gcc.info, Node: picoChip Built-in Functions, Next: PowerPC AltiVec/VSX Built-in Functions, Prev: Other MIPS Built-in Functions, Up: Target Builtins |
| |
| 6.54.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. |
| |
| |
| |
| File: gcc.info, Node: Other MIPS Built-in Functions, Next: picoChip Built-in Functions, Prev: MIPS Loongson Built-in Functions, Up: Target Builtins |
| |
| 6.54.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. |
| |
| |
| File: gcc.info, Node: PowerPC AltiVec/VSX Built-in Functions, Next: RX Built-in Functions, Prev: picoChip Built-in Functions, Up: Target Builtins |
| |
| 6.54.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 |
| |
| If `-mvsx' is used the following additional vector types are |
| implemented. |
| |
| vector unsigned long |
| vector signed long |
| vector double |
| |
| The long types are only implemented for 64-bit code generation, and |
| the long type is only used in the floating point/integer conversion |
| instructions. |
| |
| GCC's implementation of the high-level language interface available |
| from C and C++ code differs from Motorola's documentation in several |
| ways. |
| |
| * A vector constant is a list of constant expressions within curly |
| braces. |
| |
| * A vector initializer requires no cast if the vector constant is of |
| the same type as the variable it is initializing. |
| |
| * If `signed' or `unsigned' is omitted, the signedness of the vector |
| type is the default signedness of the base type. The default |
| varies depending on the operating system, so a portable program |
| should always specify the signedness. |
| |
| * Compiling with `-maltivec' adds keywords `__vector', `vector', |
| `__pixel', `pixel', `__bool' and `bool'. When compiling ISO C, |
| the context-sensitive substitution of the keywords `vector', |
| `pixel' and `bool' is disabled. To use them, you must include |
| `<altivec.h>' instead. |
| |
| * GCC allows using a `typedef' name as the type specifier for a |
| vector type. |
| |
| * For C, overloaded functions are implemented with macros so the |
| following does not work: |
| |
| vec_add ((vector signed int){1, 2, 3, 4}, foo); |
| |
| Since `vec_add' is a macro, the vector constant in the example is |
| treated as four separate arguments. Wrap the entire argument in |
| parentheses for this to work. |
| |
| _Note:_ Only the `<altivec.h>' interface is supported. Internally, |
| GCC uses built-in functions to achieve the functionality in the |
| aforementioned header file, but they are not supported and are subject |
| to change without notice. |
| |
| The following interfaces are supported for the generic and specific |
| AltiVec operations and the AltiVec predicates. In cases where there is |
| a direct mapping between generic and specific operations, only the |
| generic names are shown here, although the specific operations can also |
| be used. |
| |
| Arguments that are documented as `const int' require literal integral |
| values within the range required for that operation. |
| |
| vector signed char vec_abs (vector signed char); |
| vector signed short vec_abs (vector signed short); |
| vector signed int vec_abs (vector signed int); |
| vector float vec_abs (vector float); |
| |
| vector signed char vec_abss (vector signed char); |
| vector signed short vec_abss (vector signed short); |
| vector signed int vec_abss (vector signed int); |
| |
| vector signed char vec_add (vector bool char, vector signed char); |
| vector signed char vec_add (vector signed char, vector bool char); |
| vector signed char vec_add (vector signed char, vector signed char); |
| vector unsigned char vec_add (vector bool char, vector unsigned char); |
| vector unsigned char vec_add (vector unsigned char, vector bool char); |
| vector unsigned char vec_add (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_add (vector bool short, vector signed short); |
| vector signed short vec_add (vector signed short, vector bool short); |
| vector signed short vec_add (vector signed short, vector signed short); |
| vector unsigned short vec_add (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_add (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_add (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_add (vector bool int, vector signed int); |
| vector signed int vec_add (vector signed int, vector bool int); |
| vector signed int vec_add (vector signed int, vector signed int); |
| vector unsigned int vec_add (vector bool int, vector unsigned int); |
| vector unsigned int vec_add (vector unsigned int, vector bool int); |
| vector unsigned int vec_add (vector unsigned int, vector unsigned int); |
| vector float vec_add (vector float, vector float); |
| |
| vector float vec_vaddfp (vector float, vector float); |
| |
| vector signed int vec_vadduwm (vector bool int, vector signed int); |
| vector signed int vec_vadduwm (vector signed int, vector bool int); |
| vector signed int vec_vadduwm (vector signed int, vector signed int); |
| vector unsigned int vec_vadduwm (vector bool int, vector unsigned int); |
| vector unsigned int vec_vadduwm (vector unsigned int, vector bool int); |
| vector unsigned int vec_vadduwm (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vadduhm (vector bool short, |
| vector signed short); |
| vector signed short vec_vadduhm (vector signed short, |
| vector bool short); |
| vector signed short vec_vadduhm (vector signed short, |
| vector signed short); |
| vector unsigned short vec_vadduhm (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vadduhm (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vadduhm (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vaddubm (vector bool char, vector signed char); |
| vector signed char vec_vaddubm (vector signed char, vector bool char); |
| vector signed char vec_vaddubm (vector signed char, vector signed char); |
| vector unsigned char vec_vaddubm (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vaddubm (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vaddubm (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned int vec_addc (vector unsigned int, vector unsigned int); |
| |
| vector unsigned char vec_adds (vector bool char, vector unsigned char); |
| vector unsigned char vec_adds (vector unsigned char, vector bool char); |
| vector unsigned char vec_adds (vector unsigned char, |
| vector unsigned char); |
| vector signed char vec_adds (vector bool char, vector signed char); |
| vector signed char vec_adds (vector signed char, vector bool char); |
| vector signed char vec_adds (vector signed char, vector signed char); |
| vector unsigned short vec_adds (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_adds (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_adds (vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_adds (vector bool short, vector signed short); |
| vector signed short vec_adds (vector signed short, vector bool short); |
| vector signed short vec_adds (vector signed short, vector signed short); |
| vector unsigned int vec_adds (vector bool int, vector unsigned int); |
| vector unsigned int vec_adds (vector unsigned int, vector bool int); |
| vector unsigned int vec_adds (vector unsigned int, vector unsigned int); |
| vector signed int vec_adds (vector bool int, vector signed int); |
| vector signed int vec_adds (vector signed int, vector bool int); |
| vector signed int vec_adds (vector signed int, vector signed int); |
| |
| vector signed int vec_vaddsws (vector bool int, vector signed int); |
| vector signed int vec_vaddsws (vector signed int, vector bool int); |
| vector signed int vec_vaddsws (vector signed int, vector signed int); |
| |
| vector unsigned int vec_vadduws (vector bool int, vector unsigned int); |
| vector unsigned int vec_vadduws (vector unsigned int, vector bool int); |
| vector unsigned int vec_vadduws (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vaddshs (vector bool short, |
| vector signed short); |
| vector signed short vec_vaddshs (vector signed short, |
| vector bool short); |
| vector signed short vec_vaddshs (vector signed short, |
| vector signed short); |
| |
| vector unsigned short vec_vadduhs (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vadduhs (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vadduhs (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vaddsbs (vector bool char, vector signed char); |
| vector signed char vec_vaddsbs (vector signed char, vector bool char); |
| vector signed char vec_vaddsbs (vector signed char, vector signed char); |
| |
| vector unsigned char vec_vaddubs (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vaddubs (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vaddubs (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_and (vector float, vector float); |
| vector float vec_and (vector float, vector bool int); |
| vector float vec_and (vector bool int, vector float); |
| vector bool int vec_and (vector bool int, vector bool int); |
| vector signed int vec_and (vector bool int, vector signed int); |
| vector signed int vec_and (vector signed int, vector bool int); |
| vector signed int vec_and (vector signed int, vector signed int); |
| vector unsigned int vec_and (vector bool int, vector unsigned int); |
| vector unsigned int vec_and (vector unsigned int, vector bool int); |
| vector unsigned int vec_and (vector unsigned int, vector unsigned int); |
| vector bool short vec_and (vector bool short, vector bool short); |
| vector signed short vec_and (vector bool short, vector signed short); |
| vector signed short vec_and (vector signed short, vector bool short); |
| vector signed short vec_and (vector signed short, vector signed short); |
| vector unsigned short vec_and (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_and (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_and (vector unsigned short, |
| vector unsigned short); |
| vector signed char vec_and (vector bool char, vector signed char); |
| vector bool char vec_and (vector bool char, vector bool char); |
| vector signed char vec_and (vector signed char, vector bool char); |
| vector signed char vec_and (vector signed char, vector signed char); |
| vector unsigned char vec_and (vector bool char, vector unsigned char); |
| vector unsigned char vec_and (vector unsigned char, vector bool char); |
| vector unsigned char vec_and (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_andc (vector float, vector float); |
| vector float vec_andc (vector float, vector bool int); |
| vector float vec_andc (vector bool int, vector float); |
| vector bool int vec_andc (vector bool int, vector bool int); |
| vector signed int vec_andc (vector bool int, vector signed int); |
| vector signed int vec_andc (vector signed int, vector bool int); |
| vector signed int vec_andc (vector signed int, vector signed int); |
| vector unsigned int vec_andc (vector bool int, vector unsigned int); |
| vector unsigned int vec_andc (vector unsigned int, vector bool int); |
| vector unsigned int vec_andc (vector unsigned int, vector unsigned int); |
| vector bool short vec_andc (vector bool short, vector bool short); |
| vector signed short vec_andc (vector bool short, vector signed short); |
| vector signed short vec_andc (vector signed short, vector bool short); |
| vector signed short vec_andc (vector signed short, vector signed short); |
| vector unsigned short vec_andc (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_andc (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_andc (vector unsigned short, |
| vector unsigned short); |
| vector signed char vec_andc (vector bool char, vector signed char); |
| vector bool char vec_andc (vector bool char, vector bool char); |
| vector signed char vec_andc (vector signed char, vector bool char); |
| vector signed char vec_andc (vector signed char, vector signed char); |
| vector unsigned char vec_andc (vector bool char, vector unsigned char); |
| vector unsigned char vec_andc (vector unsigned char, vector bool char); |
| vector unsigned char vec_andc (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned char vec_avg (vector unsigned char, |
| vector unsigned char); |
| vector signed char vec_avg (vector signed char, vector signed char); |
| vector unsigned short vec_avg (vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_avg (vector signed short, vector signed short); |
| vector unsigned int vec_avg (vector unsigned int, vector unsigned int); |
| vector signed int vec_avg (vector signed int, vector signed int); |
| |
| vector signed int vec_vavgsw (vector signed int, vector signed int); |
| |
| vector unsigned int vec_vavguw (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vavgsh (vector signed short, |
| vector signed short); |
| |
| vector unsigned short vec_vavguh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vavgsb (vector signed char, vector signed char); |
| |
| vector unsigned char vec_vavgub (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_copysign (vector float); |
| |
| vector float vec_ceil (vector float); |
| |
| vector signed int vec_cmpb (vector float, vector float); |
| |
| vector bool char vec_cmpeq (vector signed char, vector signed char); |
| vector bool char vec_cmpeq (vector unsigned char, vector unsigned char); |
| vector bool short vec_cmpeq (vector signed short, vector signed short); |
| vector bool short vec_cmpeq (vector unsigned short, |
| vector unsigned short); |
| vector bool int vec_cmpeq (vector signed int, vector signed int); |
| vector bool int vec_cmpeq (vector unsigned int, vector unsigned int); |
| vector bool int vec_cmpeq (vector float, vector float); |
| |
| vector bool int vec_vcmpeqfp (vector float, vector float); |
| |
| vector bool int vec_vcmpequw (vector signed int, vector signed int); |
| vector bool int vec_vcmpequw (vector unsigned int, vector unsigned int); |
| |
| vector bool short vec_vcmpequh (vector signed short, |
| vector signed short); |
| vector bool short vec_vcmpequh (vector unsigned short, |
| vector unsigned short); |
| |
| vector bool char vec_vcmpequb (vector signed char, vector signed char); |
| vector bool char vec_vcmpequb (vector unsigned char, |
| vector unsigned char); |
| |
| vector bool int vec_cmpge (vector float, vector float); |
| |
| vector bool char vec_cmpgt (vector unsigned char, vector unsigned char); |
| vector bool char vec_cmpgt (vector signed char, vector signed char); |
| vector bool short vec_cmpgt (vector unsigned short, |
| vector unsigned short); |
| vector bool short vec_cmpgt (vector signed short, vector signed short); |
| vector bool int vec_cmpgt (vector unsigned int, vector unsigned int); |
| vector bool int vec_cmpgt (vector signed int, vector signed int); |
| vector bool int vec_cmpgt (vector float, vector float); |
| |
| vector bool int vec_vcmpgtfp (vector float, vector float); |
| |
| vector bool int vec_vcmpgtsw (vector signed int, vector signed int); |
| |
| vector bool int vec_vcmpgtuw (vector unsigned int, vector unsigned int); |
| |
| vector bool short vec_vcmpgtsh (vector signed short, |
| vector signed short); |
| |
| vector bool short vec_vcmpgtuh (vector unsigned short, |
| vector unsigned short); |
| |
| vector bool char vec_vcmpgtsb (vector signed char, vector signed char); |
| |
| vector bool char vec_vcmpgtub (vector unsigned char, |
| vector unsigned char); |
| |
| vector bool int vec_cmple (vector float, vector float); |
| |
| vector bool char vec_cmplt (vector unsigned char, vector unsigned char); |
| vector bool char vec_cmplt (vector signed char, vector signed char); |
| vector bool short vec_cmplt (vector unsigned short, |
| vector unsigned short); |
| vector bool short vec_cmplt (vector signed short, vector signed short); |
| vector bool int vec_cmplt (vector unsigned int, vector unsigned int); |
| vector bool int vec_cmplt (vector signed int, vector signed int); |
| vector bool int vec_cmplt (vector float, vector float); |
| |
| vector float vec_ctf (vector unsigned int, const int); |
| vector float vec_ctf (vector signed int, const int); |
| |
| vector float vec_vcfsx (vector signed int, const int); |
| |
| vector float vec_vcfux (vector unsigned int, const int); |
| |
| vector signed int vec_cts (vector float, const int); |
| |
| vector unsigned int vec_ctu (vector float, const int); |
| |
| void vec_dss (const int); |
| |
| void vec_dssall (void); |
| |
| void vec_dst (const vector unsigned char *, int, const int); |
| void vec_dst (const vector signed char *, int, const int); |
| void vec_dst (const vector bool char *, int, const int); |
| void vec_dst (const vector unsigned short *, int, const int); |
| void vec_dst (const vector signed short *, int, const int); |
| void vec_dst (const vector bool short *, int, const int); |
| void vec_dst (const vector pixel *, int, const int); |
| void vec_dst (const vector unsigned int *, int, const int); |
| void vec_dst (const vector signed int *, int, const int); |
| void vec_dst (const vector bool int *, int, const int); |
| void vec_dst (const vector float *, int, const int); |
| void vec_dst (const unsigned char *, int, const int); |
| void vec_dst (const signed char *, int, const int); |
| void vec_dst (const unsigned short *, int, const int); |
| void vec_dst (const short *, int, const int); |
| void vec_dst (const unsigned int *, int, const int); |
| void vec_dst (const int *, int, const int); |
| void vec_dst (const unsigned long *, int, const int); |
| void vec_dst (const long *, int, const int); |
| void vec_dst (const float *, int, const int); |
| |
| void vec_dstst (const vector unsigned char *, int, const int); |
| void vec_dstst (const vector signed char *, int, const int); |
| void vec_dstst (const vector bool char *, int, const int); |
| void vec_dstst (const vector unsigned short *, int, const int); |
| void vec_dstst (const vector signed short *, int, const int); |
| void vec_dstst (const vector bool short *, int, const int); |
| void vec_dstst (const vector pixel *, int, const int); |
| void vec_dstst (const vector unsigned int *, int, const int); |
| void vec_dstst (const vector signed int *, int, const int); |
| void vec_dstst (const vector bool int *, int, const int); |
| void vec_dstst (const vector float *, int, const int); |
| void vec_dstst (const unsigned char *, int, const int); |
| void vec_dstst (const signed char *, int, const int); |
| void vec_dstst (const unsigned short *, int, const int); |
| void vec_dstst (const short *, int, const int); |
| void vec_dstst (const unsigned int *, int, const int); |
| void vec_dstst (const int *, int, const int); |
| void vec_dstst (const unsigned long *, int, const int); |
| void vec_dstst (const long *, int, const int); |
| void vec_dstst (const float *, int, const int); |
| |
| void vec_dststt (const vector unsigned char *, int, const int); |
| void vec_dststt (const vector signed char *, int, const int); |
| void vec_dststt (const vector bool char *, int, const int); |
| void vec_dststt (const vector unsigned short *, int, const int); |
| void vec_dststt (const vector signed short *, int, const int); |
| void vec_dststt (const vector bool short *, int, const int); |
| void vec_dststt (const vector pixel *, int, const int); |
| void vec_dststt (const vector unsigned int *, int, const int); |
| void vec_dststt (const vector signed int *, int, const int); |
| void vec_dststt (const vector bool int *, int, const int); |
| void vec_dststt (const vector float *, int, const int); |
| void vec_dststt (const unsigned char *, int, const int); |
| void vec_dststt (const signed char *, int, const int); |
| void vec_dststt (const unsigned short *, int, const int); |
| void vec_dststt (const short *, int, const int); |
| void vec_dststt (const unsigned int *, int, const int); |
| void vec_dststt (const int *, int, const int); |
| void vec_dststt (const unsigned long *, int, const int); |
| void vec_dststt (const long *, int, const int); |
| void vec_dststt (const float *, int, const int); |
| |
| void vec_dstt (const vector unsigned char *, int, const int); |
| void vec_dstt (const vector signed char *, int, const int); |
| void vec_dstt (const vector bool char *, int, const int); |
| void vec_dstt (const vector unsigned short *, int, const int); |
| void vec_dstt (const vector signed short *, int, const int); |
| void vec_dstt (const vector bool short *, int, const int); |
| void vec_dstt (const vector pixel *, int, const int); |
| void vec_dstt (const vector unsigned int *, int, const int); |
| void vec_dstt (const vector signed int *, int, const int); |
| void vec_dstt (const vector bool int *, int, const int); |
| void vec_dstt (const vector float *, int, const int); |
| void vec_dstt (const unsigned char *, int, const int); |
| void vec_dstt (const signed char *, int, const int); |
| void vec_dstt (const unsigned short *, int, const int); |
| void vec_dstt (const short *, int, const int); |
| void vec_dstt (const unsigned int *, int, const int); |
| void vec_dstt (const int *, int, const int); |
| void vec_dstt (const unsigned long *, int, const int); |
| void vec_dstt (const long *, int, const int); |
| void vec_dstt (const float *, int, const int); |
| |
| vector float vec_expte (vector float); |
| |
| vector float vec_floor (vector float); |
| |
| vector float vec_ld (int, const vector float *); |
| vector float vec_ld (int, const float *); |
| vector bool int vec_ld (int, const vector bool int *); |
| vector signed int vec_ld (int, const vector signed int *); |
| vector signed int vec_ld (int, const int *); |
| vector signed int vec_ld (int, const long *); |
| vector unsigned int vec_ld (int, const vector unsigned int *); |
| vector unsigned int vec_ld (int, const unsigned int *); |
| vector unsigned int vec_ld (int, const unsigned long *); |
| vector bool short vec_ld (int, const vector bool short *); |
| vector pixel vec_ld (int, const vector pixel *); |
| vector signed short vec_ld (int, const vector signed short *); |
| vector signed short vec_ld (int, const short *); |
| vector unsigned short vec_ld (int, const vector unsigned short *); |
| vector unsigned short vec_ld (int, const unsigned short *); |
| vector bool char vec_ld (int, const vector bool char *); |
| vector signed char vec_ld (int, const vector signed char *); |
| vector signed char vec_ld (int, const signed char *); |
| vector unsigned char vec_ld (int, const vector unsigned char *); |
| vector unsigned char vec_ld (int, const unsigned char *); |
| |
| vector signed char vec_lde (int, const signed char *); |
| vector unsigned char vec_lde (int, const unsigned char *); |
| vector signed short vec_lde (int, const short *); |
| vector unsigned short vec_lde (int, const unsigned short *); |
| vector float vec_lde (int, const float *); |
| vector signed int vec_lde (int, const int *); |
| vector unsigned int vec_lde (int, const unsigned int *); |
| vector signed int vec_lde (int, const long *); |
| vector unsigned int vec_lde (int, const unsigned long *); |
| |
| vector float vec_lvewx (int, float *); |
| vector signed int vec_lvewx (int, int *); |
| vector unsigned int vec_lvewx (int, unsigned int *); |
| vector signed int vec_lvewx (int, long *); |
| vector unsigned int vec_lvewx (int, unsigned long *); |
| |
| vector signed short vec_lvehx (int, short *); |
| vector unsigned short vec_lvehx (int, unsigned short *); |
| |
| vector signed char vec_lvebx (int, char *); |
| vector unsigned char vec_lvebx (int, unsigned char *); |
| |
| vector float vec_ldl (int, const vector float *); |
| vector float vec_ldl (int, const float *); |
| vector bool int vec_ldl (int, const vector bool int *); |
| vector signed int vec_ldl (int, const vector signed int *); |
| vector signed int vec_ldl (int, const int *); |
| vector signed int vec_ldl (int, const long *); |
| vector unsigned int vec_ldl (int, const vector unsigned int *); |
| vector unsigned int vec_ldl (int, const unsigned int *); |
| vector unsigned int vec_ldl (int, const unsigned long *); |
| vector bool short vec_ldl (int, const vector bool short *); |
| vector pixel vec_ldl (int, const vector pixel *); |
| vector signed short vec_ldl (int, const vector signed short *); |
| vector signed short vec_ldl (int, const short *); |
| vector unsigned short vec_ldl (int, const vector unsigned short *); |
| vector unsigned short vec_ldl (int, const unsigned short *); |
| vector bool char vec_ldl (int, const vector bool char *); |
| vector signed char vec_ldl (int, const vector signed char *); |
| vector signed char vec_ldl (int, const signed char *); |
| vector unsigned char vec_ldl (int, const vector unsigned char *); |
| vector unsigned char vec_ldl (int, const unsigned char *); |
| |
| vector float vec_loge (vector float); |
| |
| vector unsigned char vec_lvsl (int, const volatile unsigned char *); |
| vector unsigned char vec_lvsl (int, const volatile signed char *); |
| vector unsigned char vec_lvsl (int, const volatile unsigned short *); |
| vector unsigned char vec_lvsl (int, const volatile short *); |
| vector unsigned char vec_lvsl (int, const volatile unsigned int *); |
| vector unsigned char vec_lvsl (int, const volatile int *); |
| vector unsigned char vec_lvsl (int, const volatile unsigned long *); |
| vector unsigned char vec_lvsl (int, const volatile long *); |
| vector unsigned char vec_lvsl (int, const volatile float *); |
| |
| vector unsigned char vec_lvsr (int, const volatile unsigned char *); |
| vector unsigned char vec_lvsr (int, const volatile signed char *); |
| vector unsigned char vec_lvsr (int, const volatile unsigned short *); |
| vector unsigned char vec_lvsr (int, const volatile short *); |
| vector unsigned char vec_lvsr (int, const volatile unsigned int *); |
| vector unsigned char vec_lvsr (int, const volatile int *); |
| vector unsigned char vec_lvsr (int, const volatile unsigned long *); |
| vector unsigned char vec_lvsr (int, const volatile long *); |
| vector unsigned char vec_lvsr (int, const volatile float *); |
| |
| vector float vec_madd (vector float, vector float, vector float); |
| |
| vector signed short vec_madds (vector signed short, |
| vector signed short, |
| vector signed short); |
| |
| vector unsigned char vec_max (vector bool char, vector unsigned char); |
| vector unsigned char vec_max (vector unsigned char, vector bool char); |
| vector unsigned char vec_max (vector unsigned char, |
| vector unsigned char); |
| vector signed char vec_max (vector bool char, vector signed char); |
| vector signed char vec_max (vector signed char, vector bool char); |
| vector signed char vec_max (vector signed char, vector signed char); |
| vector unsigned short vec_max (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_max (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_max (vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_max (vector bool short, vector signed short); |
| vector signed short vec_max (vector signed short, vector bool short); |
| vector signed short vec_max (vector signed short, vector signed short); |
| vector unsigned int vec_max (vector bool int, vector unsigned int); |
| vector unsigned int vec_max (vector unsigned int, vector bool int); |
| vector unsigned int vec_max (vector unsigned int, vector unsigned int); |
| vector signed int vec_max (vector bool int, vector signed int); |
| vector signed int vec_max (vector signed int, vector bool int); |
| vector signed int vec_max (vector signed int, vector signed int); |
| vector float vec_max (vector float, vector float); |
| |
| vector float vec_vmaxfp (vector float, vector float); |
| |
| vector signed int vec_vmaxsw (vector bool int, vector signed int); |
| vector signed int vec_vmaxsw (vector signed int, vector bool int); |
| vector signed int vec_vmaxsw (vector signed int, vector signed int); |
| |
| vector unsigned int vec_vmaxuw (vector bool int, vector unsigned int); |
| vector unsigned int vec_vmaxuw (vector unsigned int, vector bool int); |
| vector unsigned int vec_vmaxuw (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vmaxsh (vector bool short, vector signed short); |
| vector signed short vec_vmaxsh (vector signed short, vector bool short); |
| vector signed short vec_vmaxsh (vector signed short, |
| vector signed short); |
| |
| vector unsigned short vec_vmaxuh (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vmaxuh (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vmaxuh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vmaxsb (vector bool char, vector signed char); |
| vector signed char vec_vmaxsb (vector signed char, vector bool char); |
| vector signed char vec_vmaxsb (vector signed char, vector signed char); |
| |
| vector unsigned char vec_vmaxub (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vmaxub (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vmaxub (vector unsigned char, |
| vector unsigned char); |
| |
| vector bool char vec_mergeh (vector bool char, vector bool char); |
| vector signed char vec_mergeh (vector signed char, vector signed char); |
| vector unsigned char vec_mergeh (vector unsigned char, |
| vector unsigned char); |
| vector bool short vec_mergeh (vector bool short, vector bool short); |
| vector pixel vec_mergeh (vector pixel, vector pixel); |
| vector signed short vec_mergeh (vector signed short, |
| vector signed short); |
| vector unsigned short vec_mergeh (vector unsigned short, |
| vector unsigned short); |
| vector float vec_mergeh (vector float, vector float); |
| vector bool int vec_mergeh (vector bool int, vector bool int); |
| vector signed int vec_mergeh (vector signed int, vector signed int); |
| vector unsigned int vec_mergeh (vector unsigned int, |
| vector unsigned int); |
| |
| vector float vec_vmrghw (vector float, vector float); |
| vector bool int vec_vmrghw (vector bool int, vector bool int); |
| vector signed int vec_vmrghw (vector signed int, vector signed int); |
| vector unsigned int vec_vmrghw (vector unsigned int, |
| vector unsigned int); |
| |
| vector bool short vec_vmrghh (vector bool short, vector bool short); |
| vector signed short vec_vmrghh (vector signed short, |
| vector signed short); |
| vector unsigned short vec_vmrghh (vector unsigned short, |
| vector unsigned short); |
| vector pixel vec_vmrghh (vector pixel, vector pixel); |
| |
| vector bool char vec_vmrghb (vector bool char, vector bool char); |
| vector signed char vec_vmrghb (vector signed char, vector signed char); |
| vector unsigned char vec_vmrghb (vector unsigned char, |
| vector unsigned char); |
| |
| vector bool char vec_mergel (vector bool char, vector bool char); |
| vector signed char vec_mergel (vector signed char, vector signed char); |
| vector unsigned char vec_mergel (vector unsigned char, |
| vector unsigned char); |
| vector bool short vec_mergel (vector bool short, vector bool short); |
| vector pixel vec_mergel (vector pixel, vector pixel); |
| vector signed short vec_mergel (vector signed short, |
| vector signed short); |
| vector unsigned short vec_mergel (vector unsigned short, |
| vector unsigned short); |
| vector float vec_mergel (vector float, vector float); |
| vector bool int vec_mergel (vector bool int, vector bool int); |
| vector signed int vec_mergel (vector signed int, vector signed int); |
| vector unsigned int vec_mergel (vector unsigned int, |
| vector unsigned int); |
| |
| vector float vec_vmrglw (vector float, vector float); |
| vector signed int vec_vmrglw (vector signed int, vector signed int); |
| vector unsigned int vec_vmrglw (vector unsigned int, |
| vector unsigned int); |
| vector bool int vec_vmrglw (vector bool int, vector bool int); |
| |
| vector bool short vec_vmrglh (vector bool short, vector bool short); |
| vector signed short vec_vmrglh (vector signed short, |
| vector signed short); |
| vector unsigned short vec_vmrglh (vector unsigned short, |
| vector unsigned short); |
| vector pixel vec_vmrglh (vector pixel, vector pixel); |
| |
| vector bool char vec_vmrglb (vector bool char, vector bool char); |
| vector signed char vec_vmrglb (vector signed char, vector signed char); |
| vector unsigned char vec_vmrglb (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned short vec_mfvscr (void); |
| |
| vector unsigned char vec_min (vector bool char, vector unsigned char); |
| vector unsigned char vec_min (vector unsigned char, vector bool char); |
| vector unsigned char vec_min (vector unsigned char, |
| vector unsigned char); |
| vector signed char vec_min (vector bool char, vector signed char); |
| vector signed char vec_min (vector signed char, vector bool char); |
| vector signed char vec_min (vector signed char, vector signed char); |
| vector unsigned short vec_min (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_min (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_min (vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_min (vector bool short, vector signed short); |
| vector signed short vec_min (vector signed short, vector bool short); |
| vector signed short vec_min (vector signed short, vector signed short); |
| vector unsigned int vec_min (vector bool int, vector unsigned int); |
| vector unsigned int vec_min (vector unsigned int, vector bool int); |
| vector unsigned int vec_min (vector unsigned int, vector unsigned int); |
| vector signed int vec_min (vector bool int, vector signed int); |
| vector signed int vec_min (vector signed int, vector bool int); |
| vector signed int vec_min (vector signed int, vector signed int); |
| vector float vec_min (vector float, vector float); |
| |
| vector float vec_vminfp (vector float, vector float); |
| |
| vector signed int vec_vminsw (vector bool int, vector signed int); |
| vector signed int vec_vminsw (vector signed int, vector bool int); |
| vector signed int vec_vminsw (vector signed int, vector signed int); |
| |
| vector unsigned int vec_vminuw (vector bool int, vector unsigned int); |
| vector unsigned int vec_vminuw (vector unsigned int, vector bool int); |
| vector unsigned int vec_vminuw (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vminsh (vector bool short, vector signed short); |
| vector signed short vec_vminsh (vector signed short, vector bool short); |
| vector signed short vec_vminsh (vector signed short, |
| vector signed short); |
| |
| vector unsigned short vec_vminuh (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vminuh (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vminuh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vminsb (vector bool char, vector signed char); |
| vector signed char vec_vminsb (vector signed char, vector bool char); |
| vector signed char vec_vminsb (vector signed char, vector signed char); |
| |
| vector unsigned char vec_vminub (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vminub (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vminub (vector unsigned char, |
| vector unsigned char); |
| |
| vector signed short vec_mladd (vector signed short, |
| vector signed short, |
| vector signed short); |
| vector signed short vec_mladd (vector signed short, |
| vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_mladd (vector unsigned short, |
| vector signed short, |
| vector signed short); |
| vector unsigned short vec_mladd (vector unsigned short, |
| vector unsigned short, |
| vector unsigned short); |
| |
| vector signed short vec_mradds (vector signed short, |
| vector signed short, |
| vector signed short); |
| |
| vector unsigned int vec_msum (vector unsigned char, |
| vector unsigned char, |
| vector unsigned int); |
| vector signed int vec_msum (vector signed char, |
| vector unsigned char, |
| vector signed int); |
| vector unsigned int vec_msum (vector unsigned short, |
| vector unsigned short, |
| vector unsigned int); |
| vector signed int vec_msum (vector signed short, |
| vector signed short, |
| vector signed int); |
| |
| vector signed int vec_vmsumshm (vector signed short, |
| vector signed short, |
| vector signed int); |
| |
| vector unsigned int vec_vmsumuhm (vector unsigned short, |
| vector unsigned short, |
| vector unsigned int); |
| |
| vector signed int vec_vmsummbm (vector signed char, |
| vector unsigned char, |
| vector signed int); |
| |
| vector unsigned int vec_vmsumubm (vector unsigned char, |
| vector unsigned char, |
| vector unsigned int); |
| |
| vector unsigned int vec_msums (vector unsigned short, |
| vector unsigned short, |
| vector unsigned int); |
| vector signed int vec_msums (vector signed short, |
| vector signed short, |
| vector signed int); |
| |
| vector signed int vec_vmsumshs (vector signed short, |
| vector signed short, |
| vector signed int); |
| |
| vector unsigned int vec_vmsumuhs (vector unsigned short, |
| vector unsigned short, |
| vector unsigned int); |
| |
| void vec_mtvscr (vector signed int); |
| void vec_mtvscr (vector unsigned int); |
| void vec_mtvscr (vector bool int); |
| void vec_mtvscr (vector signed short); |
| void vec_mtvscr (vector unsigned short); |
| void vec_mtvscr (vector bool short); |
| void vec_mtvscr (vector pixel); |
| void vec_mtvscr (vector signed char); |
| void vec_mtvscr (vector unsigned char); |
| void vec_mtvscr (vector bool char); |
| |
| vector unsigned short vec_mule (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_mule (vector signed char, |
| vector signed char); |
| vector unsigned int vec_mule (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_mule (vector signed short, vector signed short); |
| |
| vector signed int vec_vmulesh (vector signed short, |
| vector signed short); |
| |
| vector unsigned int vec_vmuleuh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed short vec_vmulesb (vector signed char, |
| vector signed char); |
| |
| vector unsigned short vec_vmuleub (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned short vec_mulo (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_mulo (vector signed char, vector signed char); |
| vector unsigned int vec_mulo (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_mulo (vector signed short, vector signed short); |
| |
| vector signed int vec_vmulosh (vector signed short, |
| vector signed short); |
| |
| vector unsigned int vec_vmulouh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed short vec_vmulosb (vector signed char, |
| vector signed char); |
| |
| vector unsigned short vec_vmuloub (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_nmsub (vector float, vector float, vector float); |
| |
| vector float vec_nor (vector float, vector float); |
| vector signed int vec_nor (vector signed int, vector signed int); |
| vector unsigned int vec_nor (vector unsigned int, vector unsigned int); |
| vector bool int vec_nor (vector bool int, vector bool int); |
| vector signed short vec_nor (vector signed short, vector signed short); |
| vector unsigned short vec_nor (vector unsigned short, |
| vector unsigned short); |
| vector bool short vec_nor (vector bool short, vector bool short); |
| vector signed char vec_nor (vector signed char, vector signed char); |
| vector unsigned char vec_nor (vector unsigned char, |
| vector unsigned char); |
| vector bool char vec_nor (vector bool char, vector bool char); |
| |
| vector float vec_or (vector float, vector float); |
| vector float vec_or (vector float, vector bool int); |
| vector float vec_or (vector bool int, vector float); |
| vector bool int vec_or (vector bool int, vector bool int); |
| vector signed int vec_or (vector bool int, vector signed int); |
| vector signed int vec_or (vector signed int, vector bool int); |
| vector signed int vec_or (vector signed int, vector signed int); |
| vector unsigned int vec_or (vector bool int, vector unsigned int); |
| vector unsigned int vec_or (vector unsigned int, vector bool int); |
| vector unsigned int vec_or (vector unsigned int, vector unsigned int); |
| vector bool short vec_or (vector bool short, vector bool short); |
| vector signed short vec_or (vector bool short, vector signed short); |
| vector signed short vec_or (vector signed short, vector bool short); |
| vector signed short vec_or (vector signed short, vector signed short); |
| vector unsigned short vec_or (vector bool short, vector unsigned short); |
| vector unsigned short vec_or (vector unsigned short, vector bool short); |
| vector unsigned short vec_or (vector unsigned short, |
| vector unsigned short); |
| vector signed char vec_or (vector bool char, vector signed char); |
| vector bool char vec_or (vector bool char, vector bool char); |
| vector signed char vec_or (vector signed char, vector bool char); |
| vector signed char vec_or (vector signed char, vector signed char); |
| vector unsigned char vec_or (vector bool char, vector unsigned char); |
| vector unsigned char vec_or (vector unsigned char, vector bool char); |
| vector unsigned char vec_or (vector unsigned char, |
| vector unsigned char); |
| |
| vector signed char vec_pack (vector signed short, vector signed short); |
| vector unsigned char vec_pack (vector unsigned short, |
| vector unsigned short); |
| vector bool char vec_pack (vector bool short, vector bool short); |
| vector signed short vec_pack (vector signed int, vector signed int); |
| vector unsigned short vec_pack (vector unsigned int, |
| vector unsigned int); |
| vector bool short vec_pack (vector bool int, vector bool int); |
| |
| vector bool short vec_vpkuwum (vector bool int, vector bool int); |
| vector signed short vec_vpkuwum (vector signed int, vector signed int); |
| vector unsigned short vec_vpkuwum (vector unsigned int, |
| vector unsigned int); |
| |
| vector bool char vec_vpkuhum (vector bool short, vector bool short); |
| vector signed char vec_vpkuhum (vector signed short, |
| vector signed short); |
| vector unsigned char vec_vpkuhum (vector unsigned short, |
| vector unsigned short); |
| |
| vector pixel vec_packpx (vector unsigned int, vector unsigned int); |
| |
| vector unsigned char vec_packs (vector unsigned short, |
| vector unsigned short); |
| vector signed char vec_packs (vector signed short, vector signed short); |
| vector unsigned short vec_packs (vector unsigned int, |
| vector unsigned int); |
| vector signed short vec_packs (vector signed int, vector signed int); |
| |
| vector signed short vec_vpkswss (vector signed int, vector signed int); |
| |
| vector unsigned short vec_vpkuwus (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed char vec_vpkshss (vector signed short, |
| vector signed short); |
| |
| vector unsigned char vec_vpkuhus (vector unsigned short, |
| vector unsigned short); |
| |
| vector unsigned char vec_packsu (vector unsigned short, |
| vector unsigned short); |
| vector unsigned char vec_packsu (vector signed short, |
| vector signed short); |
| vector unsigned short vec_packsu (vector unsigned int, |
| vector unsigned int); |
| vector unsigned short vec_packsu (vector signed int, vector signed int); |
| |
| vector unsigned short vec_vpkswus (vector signed int, |
| vector signed int); |
| |
| vector unsigned char vec_vpkshus (vector signed short, |
| vector signed short); |
| |
| vector float vec_perm (vector float, |
| vector float, |
| vector unsigned char); |
| vector signed int vec_perm (vector signed int, |
| vector signed int, |
| vector unsigned char); |
| vector unsigned int vec_perm (vector unsigned int, |
| vector unsigned int, |
| vector unsigned char); |
| vector bool int vec_perm (vector bool int, |
| vector bool int, |
| vector unsigned char); |
| vector signed short vec_perm (vector signed short, |
| vector signed short, |
| vector unsigned char); |
| vector unsigned short vec_perm (vector unsigned short, |
| vector unsigned short, |
| vector unsigned char); |
| vector bool short vec_perm (vector bool short, |
| vector bool short, |
| vector unsigned char); |
| vector pixel vec_perm (vector pixel, |
| vector pixel, |
| vector unsigned char); |
| vector signed char vec_perm (vector signed char, |
| vector signed char, |
| vector unsigned char); |
| vector unsigned char vec_perm (vector unsigned char, |
| vector unsigned char, |
| vector unsigned char); |
| vector bool char vec_perm (vector bool char, |
| vector bool char, |
| vector unsigned char); |
| |
| vector float vec_re (vector float); |
| |
| vector signed char vec_rl (vector signed char, |
| vector unsigned char); |
| vector unsigned char vec_rl (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_rl (vector signed short, vector unsigned short); |
| vector unsigned short vec_rl (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_rl (vector signed int, vector unsigned int); |
| vector unsigned int vec_rl (vector unsigned int, vector unsigned int); |
| |
| vector signed int vec_vrlw (vector signed int, vector unsigned int); |
| vector unsigned int vec_vrlw (vector unsigned int, vector unsigned int); |
| |
| vector signed short vec_vrlh (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_vrlh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vrlb (vector signed char, vector unsigned char); |
| vector unsigned char vec_vrlb (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_round (vector float); |
| |
| vector float vec_recip (vector float, vector float); |
| |
| vector float vec_rsqrt (vector float); |
| |
| vector float vec_rsqrte (vector float); |
| |
| vector float vec_sel (vector float, vector float, vector bool int); |
| vector float vec_sel (vector float, vector float, vector unsigned int); |
| vector signed int vec_sel (vector signed int, |
| vector signed int, |
| vector bool int); |
| vector signed int vec_sel (vector signed int, |
| vector signed int, |
| vector unsigned int); |
| vector unsigned int vec_sel (vector unsigned int, |
| vector unsigned int, |
| vector bool int); |
| vector unsigned int vec_sel (vector unsigned int, |
| vector unsigned int, |
| vector unsigned int); |
| vector bool int vec_sel (vector bool int, |
| vector bool int, |
| vector bool int); |
| vector bool int vec_sel (vector bool int, |
| vector bool int, |
| vector unsigned int); |
| vector signed short vec_sel (vector signed short, |
| vector signed short, |
| vector bool short); |
| vector signed short vec_sel (vector signed short, |
| vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_sel (vector unsigned short, |
| vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_sel (vector unsigned short, |
| vector unsigned short, |
| vector unsigned short); |
| vector bool short vec_sel (vector bool short, |
| vector bool short, |
| vector bool short); |
| vector bool short vec_sel (vector bool short, |
| vector bool short, |
| vector unsigned short); |
| vector signed char vec_sel (vector signed char, |
| vector signed char, |
| vector bool char); |
| vector signed char vec_sel (vector signed char, |
| vector signed char, |
| vector unsigned char); |
| vector unsigned char vec_sel (vector unsigned char, |
| vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_sel (vector unsigned char, |
| vector unsigned char, |
| vector unsigned char); |
| vector bool char vec_sel (vector bool char, |
| vector bool char, |
| vector bool char); |
| vector bool char vec_sel (vector bool char, |
| vector bool char, |
| vector unsigned char); |
| |
| vector signed char vec_sl (vector signed char, |
| vector unsigned char); |
| vector unsigned char vec_sl (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_sl (vector signed short, vector unsigned short); |
| vector unsigned short vec_sl (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_sl (vector signed int, vector unsigned int); |
| vector unsigned int vec_sl (vector unsigned int, vector unsigned int); |
| |
| vector signed int vec_vslw (vector signed int, vector unsigned int); |
| vector unsigned int vec_vslw (vector unsigned int, vector unsigned int); |
| |
| vector signed short vec_vslh (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_vslh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vslb (vector signed char, vector unsigned char); |
| vector unsigned char vec_vslb (vector unsigned char, |
| vector unsigned char); |
| |
| vector float vec_sld (vector float, vector float, const int); |
| vector signed int vec_sld (vector signed int, |
| vector signed int, |
| const int); |
| vector unsigned int vec_sld (vector unsigned int, |
| vector unsigned int, |
| const int); |
| vector bool int vec_sld (vector bool int, |
| vector bool int, |
| const int); |
| vector signed short vec_sld (vector signed short, |
| vector signed short, |
| const int); |
| vector unsigned short vec_sld (vector unsigned short, |
| vector unsigned short, |
| const int); |
| vector bool short vec_sld (vector bool short, |
| vector bool short, |
| const int); |
| vector pixel vec_sld (vector pixel, |
| vector pixel, |
| const int); |
| vector signed char vec_sld (vector signed char, |
| vector signed char, |
| const int); |
| vector unsigned char vec_sld (vector unsigned char, |
| vector unsigned char, |
| const int); |
| vector bool char vec_sld (vector bool char, |
| vector bool char, |
| const int); |
| |
| vector signed int vec_sll (vector signed int, |
| vector unsigned int); |
| vector signed int vec_sll (vector signed int, |
| vector unsigned short); |
| vector signed int vec_sll (vector signed int, |
| vector unsigned char); |
| vector unsigned int vec_sll (vector unsigned int, |
| vector unsigned int); |
| vector unsigned int vec_sll (vector unsigned int, |
| vector unsigned short); |
| vector unsigned int vec_sll (vector unsigned int, |
| vector unsigned char); |
| vector bool int vec_sll (vector bool int, |
| vector unsigned int); |
| vector bool int vec_sll (vector bool int, |
| vector unsigned short); |
| vector bool int vec_sll (vector bool int, |
| vector unsigned char); |
| vector signed short vec_sll (vector signed short, |
| vector unsigned int); |
| vector signed short vec_sll (vector signed short, |
| vector unsigned short); |
| vector signed short vec_sll (vector signed short, |
| vector unsigned char); |
| vector unsigned short vec_sll (vector unsigned short, |
| vector unsigned int); |
| vector unsigned short vec_sll (vector unsigned short, |
| vector unsigned short); |
| vector unsigned short vec_sll (vector unsigned short, |
| vector unsigned char); |
| vector bool short vec_sll (vector bool short, vector unsigned int); |
| vector bool short vec_sll (vector bool short, vector unsigned short); |
| vector bool short vec_sll (vector bool short, vector unsigned char); |
| vector pixel vec_sll (vector pixel, vector unsigned int); |
| vector pixel vec_sll (vector pixel, vector unsigned short); |
| vector pixel vec_sll (vector pixel, vector unsigned char); |
| vector signed char vec_sll (vector signed char, vector unsigned int); |
| vector signed char vec_sll (vector signed char, vector unsigned short); |
| vector signed char vec_sll (vector signed char, vector unsigned char); |
| vector unsigned char vec_sll (vector unsigned char, |
| vector unsigned int); |
| vector unsigned char vec_sll (vector unsigned char, |
| vector unsigned short); |
| vector unsigned char vec_sll (vector unsigned char, |
| vector unsigned char); |
| vector bool char vec_sll (vector bool char, vector unsigned int); |
| vector bool char vec_sll (vector bool char, vector unsigned short); |
| vector bool char vec_sll (vector bool char, vector unsigned char); |
| |
| vector float vec_slo (vector float, vector signed char); |
| vector float vec_slo (vector float, vector unsigned char); |
| vector signed int vec_slo (vector signed int, vector signed char); |
| vector signed int vec_slo (vector signed int, vector unsigned char); |
| vector unsigned int vec_slo (vector unsigned int, vector signed char); |
| vector unsigned int vec_slo (vector unsigned int, vector unsigned char); |
| vector signed short vec_slo (vector signed short, vector signed char); |
| vector signed short vec_slo (vector signed short, vector unsigned char); |
| vector unsigned short vec_slo (vector unsigned short, |
| vector signed char); |
| vector unsigned short vec_slo (vector unsigned short, |
| vector unsigned char); |
| vector pixel vec_slo (vector pixel, vector signed char); |
| vector pixel vec_slo (vector pixel, vector unsigned char); |
| vector signed char vec_slo (vector signed char, vector signed char); |
| vector signed char vec_slo (vector signed char, vector unsigned char); |
| vector unsigned char vec_slo (vector unsigned char, vector signed char); |
| vector unsigned char vec_slo (vector unsigned char, |
| vector unsigned char); |
| |
| vector signed char vec_splat (vector signed char, const int); |
| vector unsigned char vec_splat (vector unsigned char, const int); |
| vector bool char vec_splat (vector bool char, const int); |
| vector signed short vec_splat (vector signed short, const int); |
| vector unsigned short vec_splat (vector unsigned short, const int); |
| vector bool short vec_splat (vector bool short, const int); |
| vector pixel vec_splat (vector pixel, const int); |
| vector float vec_splat (vector float, const int); |
| vector signed int vec_splat (vector signed int, const int); |
| vector unsigned int vec_splat (vector unsigned int, const int); |
| vector bool int vec_splat (vector bool int, const int); |
| |
| vector float vec_vspltw (vector float, const int); |
| vector signed int vec_vspltw (vector signed int, const int); |
| vector unsigned int vec_vspltw (vector unsigned int, const int); |
| vector bool int vec_vspltw (vector bool int, const int); |
| |
| vector bool short vec_vsplth (vector bool short, const int); |
| vector signed short vec_vsplth (vector signed short, const int); |
| vector unsigned short vec_vsplth (vector unsigned short, const int); |
| vector pixel vec_vsplth (vector pixel, const int); |
| |
| vector signed char vec_vspltb (vector signed char, const int); |
| vector unsigned char vec_vspltb (vector unsigned char, const int); |
| vector bool char vec_vspltb (vector bool char, const int); |
| |
| vector signed char vec_splat_s8 (const int); |
| |
| vector signed short vec_splat_s16 (const int); |
| |
| vector signed int vec_splat_s32 (const int); |
| |
| vector unsigned char vec_splat_u8 (const int); |
| |
| vector unsigned short vec_splat_u16 (const int); |
| |
| vector unsigned int vec_splat_u32 (const int); |
| |
| vector signed char vec_sr (vector signed char, vector unsigned char); |
| vector unsigned char vec_sr (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_sr (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_sr (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_sr (vector signed int, vector unsigned int); |
| vector unsigned int vec_sr (vector unsigned int, vector unsigned int); |
| |
| vector signed int vec_vsrw (vector signed int, vector unsigned int); |
| vector unsigned int vec_vsrw (vector unsigned int, vector unsigned int); |
| |
| vector signed short vec_vsrh (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_vsrh (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vsrb (vector signed char, vector unsigned char); |
| vector unsigned char vec_vsrb (vector unsigned char, |
| vector unsigned char); |
| |
| vector signed char vec_sra (vector signed char, vector unsigned char); |
| vector unsigned char vec_sra (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_sra (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_sra (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_sra (vector signed int, vector unsigned int); |
| vector unsigned int vec_sra (vector unsigned int, vector unsigned int); |
| |
| vector signed int vec_vsraw (vector signed int, vector unsigned int); |
| vector unsigned int vec_vsraw (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vsrah (vector signed short, |
| vector unsigned short); |
| vector unsigned short vec_vsrah (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vsrab (vector signed char, vector unsigned char); |
| vector unsigned char vec_vsrab (vector unsigned char, |
| vector unsigned char); |
| |
| vector signed int vec_srl (vector signed int, vector unsigned int); |
| vector signed int vec_srl (vector signed int, vector unsigned short); |
| vector signed int vec_srl (vector signed int, vector unsigned char); |
| vector unsigned int vec_srl (vector unsigned int, vector unsigned int); |
| vector unsigned int vec_srl (vector unsigned int, |
| vector unsigned short); |
| vector unsigned int vec_srl (vector unsigned int, vector unsigned char); |
| vector bool int vec_srl (vector bool int, vector unsigned int); |
| vector bool int vec_srl (vector bool int, vector unsigned short); |
| vector bool int vec_srl (vector bool int, vector unsigned char); |
| vector signed short vec_srl (vector signed short, vector unsigned int); |
| vector signed short vec_srl (vector signed short, |
| vector unsigned short); |
| vector signed short vec_srl (vector signed short, vector unsigned char); |
| vector unsigned short vec_srl (vector unsigned short, |
| vector unsigned int); |
| vector unsigned short vec_srl (vector unsigned short, |
| vector unsigned short); |
| vector unsigned short vec_srl (vector unsigned short, |
| vector unsigned char); |
| vector bool short vec_srl (vector bool short, vector unsigned int); |
| vector bool short vec_srl (vector bool short, vector unsigned short); |
| vector bool short vec_srl (vector bool short, vector unsigned char); |
| vector pixel vec_srl (vector pixel, vector unsigned int); |
| vector pixel vec_srl (vector pixel, vector unsigned short); |
| vector pixel vec_srl (vector pixel, vector unsigned char); |
| vector signed char vec_srl (vector signed char, vector unsigned int); |
| vector signed char vec_srl (vector signed char, vector unsigned short); |
| vector signed char vec_srl (vector signed char, vector unsigned char); |
| vector unsigned char vec_srl (vector unsigned char, |
| vector unsigned int); |
| vector unsigned char vec_srl (vector unsigned char, |
| vector unsigned short); |
| vector unsigned char vec_srl (vector unsigned char, |
| vector unsigned char); |
| vector bool char vec_srl (vector bool char, vector unsigned int); |
| vector bool char vec_srl (vector bool char, vector unsigned short); |
| vector bool char vec_srl (vector bool char, vector unsigned char); |
| |
| vector float vec_sro (vector float, vector signed char); |
| vector float vec_sro (vector float, vector unsigned char); |
| vector signed int vec_sro (vector signed int, vector signed char); |
| vector signed int vec_sro (vector signed int, vector unsigned char); |
| vector unsigned int vec_sro (vector unsigned int, vector signed char); |
| vector unsigned int vec_sro (vector unsigned int, vector unsigned char); |
| vector signed short vec_sro (vector signed short, vector signed char); |
| vector signed short vec_sro (vector signed short, vector unsigned char); |
| vector unsigned short vec_sro (vector unsigned short, |
| vector signed char); |
| vector unsigned short vec_sro (vector unsigned short, |
| vector unsigned char); |
| vector pixel vec_sro (vector pixel, vector signed char); |
| vector pixel vec_sro (vector pixel, vector unsigned char); |
| vector signed char vec_sro (vector signed char, vector signed char); |
| vector signed char vec_sro (vector signed char, vector unsigned char); |
| vector unsigned char vec_sro (vector unsigned char, vector signed char); |
| vector unsigned char vec_sro (vector unsigned char, |
| vector unsigned char); |
| |
| void vec_st (vector float, int, vector float *); |
| void vec_st (vector float, int, float *); |
| void vec_st (vector signed int, int, vector signed int *); |
| void vec_st (vector signed int, int, int *); |
| void vec_st (vector unsigned int, int, vector unsigned int *); |
| void vec_st (vector unsigned int, int, unsigned int *); |
| void vec_st (vector bool int, int, vector bool int *); |
| void vec_st (vector bool int, int, unsigned int *); |
| void vec_st (vector bool int, int, int *); |
| void vec_st (vector signed short, int, vector signed short *); |
| void vec_st (vector signed short, int, short *); |
| void vec_st (vector unsigned short, int, vector unsigned short *); |
| void vec_st (vector unsigned short, int, unsigned short *); |
| void vec_st (vector bool short, int, vector bool short *); |
| void vec_st (vector bool short, int, unsigned short *); |
| void vec_st (vector pixel, int, vector pixel *); |
| void vec_st (vector pixel, int, unsigned short *); |
| void vec_st (vector pixel, int, short *); |
| void vec_st (vector bool short, int, short *); |
| void vec_st (vector signed char, int, vector signed char *); |
| void vec_st (vector signed char, int, signed char *); |
| void vec_st (vector unsigned char, int, vector unsigned char *); |
| void vec_st (vector unsigned char, int, unsigned char *); |
| void vec_st (vector bool char, int, vector bool char *); |
| void vec_st (vector bool char, int, unsigned char *); |
| void vec_st (vector bool char, int, signed char *); |
| |
| void vec_ste (vector signed char, int, signed char *); |
| void vec_ste (vector unsigned char, int, unsigned char *); |
| void vec_ste (vector bool char, int, signed char *); |
| void vec_ste (vector bool char, int, unsigned char *); |
| void vec_ste (vector signed short, int, short *); |
| void vec_ste (vector unsigned short, int, unsigned short *); |
| void vec_ste (vector bool short, int, short *); |
| void vec_ste (vector bool short, int, unsigned short *); |
| void vec_ste (vector pixel, int, short *); |
| void vec_ste (vector pixel, int, unsigned short *); |
| void vec_ste (vector float, int, float *); |
| void vec_ste (vector signed int, int, int *); |
| void vec_ste (vector unsigned int, int, unsigned int *); |
| void vec_ste (vector bool int, int, int *); |
| void vec_ste (vector bool int, int, unsigned int *); |
| |
| void vec_stvewx (vector float, int, float *); |
| void vec_stvewx (vector signed int, int, int *); |
| void vec_stvewx (vector unsigned int, int, unsigned int *); |
| void vec_stvewx (vector bool int, int, int *); |
| void vec_stvewx (vector bool int, int, unsigned int *); |
| |
| void vec_stvehx (vector signed short, int, short *); |
| void vec_stvehx (vector unsigned short, int, unsigned short *); |
| void vec_stvehx (vector bool short, int, short *); |
| void vec_stvehx (vector bool short, int, unsigned short *); |
| void vec_stvehx (vector pixel, int, short *); |
| void vec_stvehx (vector pixel, int, unsigned short *); |
| |
| void vec_stvebx (vector signed char, int, signed char *); |
| void vec_stvebx (vector unsigned char, int, unsigned char *); |
| void vec_stvebx (vector bool char, int, signed char *); |
| void vec_stvebx (vector bool char, int, unsigned char *); |
| |
| void vec_stl (vector float, int, vector float *); |
| void vec_stl (vector float, int, float *); |
| void vec_stl (vector signed int, int, vector signed int *); |
| void vec_stl (vector signed int, int, int *); |
| void vec_stl (vector unsigned int, int, vector unsigned int *); |
| void vec_stl (vector unsigned int, int, unsigned int *); |
| void vec_stl (vector bool int, int, vector bool int *); |
| void vec_stl (vector bool int, int, unsigned int *); |
| void vec_stl (vector bool int, int, int *); |
| void vec_stl (vector signed short, int, vector signed short *); |
| void vec_stl (vector signed short, int, short *); |
| void vec_stl (vector unsigned short, int, vector unsigned short *); |
| void vec_stl (vector unsigned short, int, unsigned short *); |
| void vec_stl (vector bool short, int, vector bool short *); |
| void vec_stl (vector bool short, int, unsigned short *); |
| void vec_stl (vector bool short, int, short *); |
| void vec_stl (vector pixel, int, vector pixel *); |
| void vec_stl (vector pixel, int, unsigned short *); |
| void vec_stl (vector pixel, int, short *); |
| void vec_stl (vector signed char, int, vector signed char *); |
| void vec_stl (vector signed char, int, signed char *); |
| void vec_stl (vector unsigned char, int, vector unsigned char *); |
| void vec_stl (vector unsigned char, int, unsigned char *); |
| void vec_stl (vector bool char, int, vector bool char *); |
| void vec_stl (vector bool char, int, unsigned char *); |
| void vec_stl (vector bool char, int, signed char *); |
| |
| vector signed char vec_sub (vector bool char, vector signed char); |
| vector signed char vec_sub (vector signed char, vector bool char); |
| vector signed char vec_sub (vector signed char, vector signed char); |
| vector unsigned char vec_sub (vector bool char, vector unsigned char); |
| vector unsigned char vec_sub (vector unsigned char, vector bool char); |
| vector unsigned char vec_sub (vector unsigned char, |
| vector unsigned char); |
| vector signed short vec_sub (vector bool short, vector signed short); |
| vector signed short vec_sub (vector signed short, vector bool short); |
| vector signed short vec_sub (vector signed short, vector signed short); |
| vector unsigned short vec_sub (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_sub (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_sub (vector unsigned short, |
| vector unsigned short); |
| vector signed int vec_sub (vector bool int, vector signed int); |
| vector signed int vec_sub (vector signed int, vector bool int); |
| vector signed int vec_sub (vector signed int, vector signed int); |
| vector unsigned int vec_sub (vector bool int, vector unsigned int); |
| vector unsigned int vec_sub (vector unsigned int, vector bool int); |
| vector unsigned int vec_sub (vector unsigned int, vector unsigned int); |
| vector float vec_sub (vector float, vector float); |
| |
| vector float vec_vsubfp (vector float, vector float); |
| |
| vector signed int vec_vsubuwm (vector bool int, vector signed int); |
| vector signed int vec_vsubuwm (vector signed int, vector bool int); |
| vector signed int vec_vsubuwm (vector signed int, vector signed int); |
| vector unsigned int vec_vsubuwm (vector bool int, vector unsigned int); |
| vector unsigned int vec_vsubuwm (vector unsigned int, vector bool int); |
| vector unsigned int vec_vsubuwm (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vsubuhm (vector bool short, |
| vector signed short); |
| vector signed short vec_vsubuhm (vector signed short, |
| vector bool short); |
| vector signed short vec_vsubuhm (vector signed short, |
| vector signed short); |
| vector unsigned short vec_vsubuhm (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vsubuhm (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vsubuhm (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vsububm (vector bool char, vector signed char); |
| vector signed char vec_vsububm (vector signed char, vector bool char); |
| vector signed char vec_vsububm (vector signed char, vector signed char); |
| vector unsigned char vec_vsububm (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vsububm (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vsububm (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned int vec_subc (vector unsigned int, vector unsigned int); |
| |
| vector unsigned char vec_subs (vector bool char, vector unsigned char); |
| vector unsigned char vec_subs (vector unsigned char, vector bool char); |
| vector unsigned char vec_subs (vector unsigned char, |
| vector unsigned char); |
| vector signed char vec_subs (vector bool char, vector signed char); |
| vector signed char vec_subs (vector signed char, vector bool char); |
| vector signed char vec_subs (vector signed char, vector signed char); |
| vector unsigned short vec_subs (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_subs (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_subs (vector unsigned short, |
| vector unsigned short); |
| vector signed short vec_subs (vector bool short, vector signed short); |
| vector signed short vec_subs (vector signed short, vector bool short); |
| vector signed short vec_subs (vector signed short, vector signed short); |
| vector unsigned int vec_subs (vector bool int, vector unsigned int); |
| vector unsigned int vec_subs (vector unsigned int, vector bool int); |
| vector unsigned int vec_subs (vector unsigned int, vector unsigned int); |
| vector signed int vec_subs (vector bool int, vector signed int); |
| vector signed int vec_subs (vector signed int, vector bool int); |
| vector signed int vec_subs (vector signed int, vector signed int); |
| |
| vector signed int vec_vsubsws (vector bool int, vector signed int); |
| vector signed int vec_vsubsws (vector signed int, vector bool int); |
| vector signed int vec_vsubsws (vector signed int, vector signed int); |
| |
| vector unsigned int vec_vsubuws (vector bool int, vector unsigned int); |
| vector unsigned int vec_vsubuws (vector unsigned int, vector bool int); |
| vector unsigned int vec_vsubuws (vector unsigned int, |
| vector unsigned int); |
| |
| vector signed short vec_vsubshs (vector bool short, |
| vector signed short); |
| vector signed short vec_vsubshs (vector signed short, |
| vector bool short); |
| vector signed short vec_vsubshs (vector signed short, |
| vector signed short); |
| |
| vector unsigned short vec_vsubuhs (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_vsubuhs (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_vsubuhs (vector unsigned short, |
| vector unsigned short); |
| |
| vector signed char vec_vsubsbs (vector bool char, vector signed char); |
| vector signed char vec_vsubsbs (vector signed char, vector bool char); |
| vector signed char vec_vsubsbs (vector signed char, vector signed char); |
| |
| vector unsigned char vec_vsububs (vector bool char, |
| vector unsigned char); |
| vector unsigned char vec_vsububs (vector unsigned char, |
| vector bool char); |
| vector unsigned char vec_vsububs (vector unsigned char, |
| vector unsigned char); |
| |
| vector unsigned int vec_sum4s (vector unsigned char, |
| vector unsigned int); |
| vector signed int vec_sum4s (vector signed char, vector signed int); |
| vector signed int vec_sum4s (vector signed short, vector signed int); |
| |
| vector signed int vec_vsum4shs (vector signed short, vector signed int); |
| |
| vector signed int vec_vsum4sbs (vector signed char, vector signed int); |
| |
| vector unsigned int vec_vsum4ubs (vector unsigned char, |
| vector unsigned int); |
| |
| vector signed int vec_sum2s (vector signed int, vector signed int); |
| |
| vector signed int vec_sums (vector signed int, vector signed int); |
| |
| vector float vec_trunc (vector float); |
| |
| vector signed short vec_unpackh (vector signed char); |
| vector bool short vec_unpackh (vector bool char); |
| vector signed int vec_unpackh (vector signed short); |
| vector bool int vec_unpackh (vector bool short); |
| vector unsigned int vec_unpackh (vector pixel); |
| |
| vector bool int vec_vupkhsh (vector bool short); |
| vector signed int vec_vupkhsh (vector signed short); |
| |
| vector unsigned int vec_vupkhpx (vector pixel); |
| |
| vector bool short vec_vupkhsb (vector bool char); |
| vector signed short vec_vupkhsb (vector signed char); |
| |
| vector signed short vec_unpackl (vector signed char); |
| vector bool short vec_unpackl (vector bool char); |
| vector unsigned int vec_unpackl (vector pixel); |
| vector signed int vec_unpackl (vector signed short); |
| vector bool int vec_unpackl (vector bool short); |
| |
| vector unsigned int vec_vupklpx (vector pixel); |
| |
| vector bool int vec_vupklsh (vector bool short); |
| vector signed int vec_vupklsh (vector signed short); |
| |
| vector bool short vec_vupklsb (vector bool char); |
| vector signed short vec_vupklsb (vector signed char); |
| |
| vector float vec_xor (vector float, vector float); |
| vector float vec_xor (vector float, vector bool int); |
| vector float vec_xor (vector bool int, vector float); |
| vector bool int vec_xor (vector bool int, vector bool int); |
| vector signed int vec_xor (vector bool int, vector signed int); |
| vector signed int vec_xor (vector signed int, vector bool int); |
| vector signed int vec_xor (vector signed int, vector signed int); |
| vector unsigned int vec_xor (vector bool int, vector unsigned int); |
| vector unsigned int vec_xor (vector unsigned int, vector bool int); |
| vector unsigned int vec_xor (vector unsigned int, vector unsigned int); |
| vector bool short vec_xor (vector bool short, vector bool short); |
| vector signed short vec_xor (vector bool short, vector signed short); |
| vector signed short vec_xor (vector signed short, vector bool short); |
| vector signed short vec_xor (vector signed short, vector signed short); |
| vector unsigned short vec_xor (vector bool short, |
| vector unsigned short); |
| vector unsigned short vec_xor (vector unsigned short, |
| vector bool short); |
| vector unsigned short vec_xor (vector unsigned short, |
| vector unsigned short); |
| vector signed char vec_xor (vector bool char, vector signed char); |
| vector bool char vec_xor (vector bool char, vector bool char); |
| vector signed char vec_xor (vector signed char, vector bool char); |
| vector signed char vec_xor (vector signed char, vector signed char); |
| vector unsigned char vec_xor (vector bool char, vector unsigned char); |
| vector unsigned char vec_xor (vector unsigned char, vector bool char); |
| vector unsigned char vec_xor (vector unsigned char, |
| vector unsigned char); |
| |
| int vec_all_eq (vector signed char, vector bool char); |
| int vec_all_eq (vector signed char, vector signed char); |
| int vec_all_eq (vector unsigned char, vector bool char); |
| int vec_all_eq (vector unsigned char, vector unsigned char); |
| int vec_all_eq (vector bool char, vector bool char); |
| int vec_all_eq (vector bool char, vector unsigned char); |
| int vec_all_eq (vector bool char, vector signed char); |
| int vec_all_eq (vector signed short, vector bool short); |
| int vec_all_eq (vector signed short, vector signed short); |
| int vec_all_eq (vector unsigned short, vector bool short); |
| int vec_all_eq (vector unsigned short, vector unsigned short); |
| int vec_all_eq (vector bool short, vector bool short); |
| int vec_all_eq (vector bool short, vector unsigned short); |
| int vec_all_eq (vector bool short, vector signed short); |
| int vec_all_eq (vector pixel, vector pixel); |
| int vec_all_eq (vector signed int, vector bool int); |
| int vec_all_eq (vector signed int, vector signed int); |
| int vec_all_eq (vector unsigned int, vector bool int); |
| int vec_all_eq (vector unsigned int, vector unsigned int); |
| int vec_all_eq (vector bool int, vector bool int); |
| int vec_all_eq (vector bool int, vector unsigned int); |
| int vec_all_eq (vector bool int, vector signed int); |
| int vec_all_eq (vector float, vector float); |
| |
| int vec_all_ge (vector bool char, vector unsigned char); |
| int vec_all_ge (vector unsigned char, vector bool char); |
| int vec_all_ge (vector unsigned char, vector unsigned char); |
| int vec_all_ge (vector bool char, vector signed char); |
| int vec_all_ge (vector signed char, vector bool char); |
| int vec_all_ge (vector signed char, vector signed char); |
| int vec_all_ge (vector bool short, vector unsigned short); |
| int vec_all_ge (vector unsigned short, vector bool short); |
| int vec_all_ge (vector unsigned short, vector unsigned short); |
| int vec_all_ge (vector signed short, vector signed short); |
| int vec_all_ge (vector bool short, vector signed short); |
| int vec_all_ge (vector signed short, vector bool short); |
| int vec_all_ge (vector bool int, vector unsigned int); |
| int vec_all_ge (vector unsigned int, vector bool int); |
| int vec_all_ge (vector unsigned int, vector unsigned int); |
| int vec_all_ge (vector bool int, vector signed int); |
| int vec_all_ge (vector signed int, vector bool int); |
| int vec_all_ge (vector signed int, vector signed int); |
| int vec_all_ge (vector float, vector float); |
| |
| int vec_all_gt (vector bool char, vector unsigned char); |
| int vec_all_gt (vector unsigned char, vector bool char); |
| int vec_all_gt (vector unsigned char, vector unsigned char); |
| int vec_all_gt (vector bool char, vector signed char); |
| int vec_all_gt (vector signed char, vector bool char); |
| int vec_all_gt (vector signed char, vector signed char); |
| int vec_all_gt (vector bool short, vector unsigned short); |
| int vec_all_gt (vector unsigned short, vector bool short); |
| int vec_all_gt (vector unsigned short, vector unsigned short); |
| int vec_all_gt (vector bool short, vector signed short); |
| int vec_all_gt (vector signed short, vector bool short); |
| int vec_all_gt (vector signed short, vector signed short); |
| int vec_all_gt (vector bool int, vector unsigned int); |
| int vec_all_gt (vector unsigned int, vector bool int); |
| int vec_all_gt (vector unsigned int, vector unsigned int); |
| int vec_all_gt (vector bool int, vector signed int); |
| int vec_all_gt (vector signed int, vector bool int); |
| int vec_all_gt (vector signed int, vector signed int); |
| int vec_all_gt (vector float, vector float); |
| |
| int vec_all_in (vector float, vector float); |
| |
| int vec_all_le (vector bool char, vector unsigned char); |
| int vec_all_le (vector unsigned char, vector bool char); |
| int vec_all_le (vector unsigned char, vector unsigned char); |
| int vec_all_le (vector bool char, vector signed char); |
| int vec_all_le (vector signed char, vector bool char); |
| int vec_all_le (vector signed char, vector signed char); |
| int vec_all_le (vector bool short, vector unsigned short); |
| int vec_all_le (vector unsigned short, vector bool short); |
| int vec_all_le (vector unsigned short, vector unsigned short); |
| int vec_all_le (vector bool short, vector signed short); |
| int vec_all_le (vector signed short, vector bool short); |
| int vec_all_le (vector signed short, vector signed short); |
| int vec_all_le (vector bool int, vector unsigned int); |
| int vec_all_le (vector unsigned int, vector bool int); |
| int vec_all_le (vector unsigned int, vector unsigned int); |
| int vec_all_le (vector bool int, vector signed int); |
| int vec_all_le (vector signed int, vector bool int); |
| int vec_all_le (vector signed int, vector signed int); |
| int vec_all_le (vector float, vector float); |
| |
| int vec_all_lt (vector bool char, vector unsigned char); |
| int vec_all_lt (vector unsigned char, vector bool char); |
| int vec_all_lt (vector unsigned char, vector unsigned char); |
| int vec_all_lt (vector bool char, vector signed char); |
| int vec_all_lt (vector signed char, vector bool char); |
| int vec_all_lt (vector signed char, vector signed char); |
| int vec_all_lt (vector bool short, vector unsigned short); |
| int vec_all_lt (vector unsigned short, vector bool short); |
| int vec_all_lt (vector unsigned short, vector unsigned short); |
| int vec_all_lt (vector bool short, vector signed short); |
| int vec_all_lt (vector signed short, vector bool short); |
| int vec_all_lt (vector signed short, vector signed short); |
| int vec_all_lt (vector bool int, vector unsigned int); |
| int vec_all_lt (vector unsigned int, vector bool int); |
| int vec_all_lt (vector unsigned int, vector unsigned int); |
| int vec_all_lt (vector bool int, vector signed int); |
| int vec_all_lt (vector signed int, vector bool int); |
| int vec_all_lt (vector signed int, vector signed int); |
| int vec_all_lt (vector float, vector float); |
| |
| int vec_all_nan (vector float); |
| |
| int vec_all_ne (vector signed char, vector bool char); |
| int vec_all_ne (vector signed char, vector signed char); |
| int vec_all_ne (vector unsigned char, vector bool char); |
| int vec_all_ne (vector unsigned char, vector unsigned char); |
| int vec_all_ne (vector bool char, vector bool char); |
| int vec_all_ne (vector bool char, vector unsigned char); |
| int vec_all_ne (vector bool char, vector signed char); |
| int vec_all_ne (vector signed short, vector bool short); |
| int vec_all_ne (vector signed short, vector signed short); |
| int vec_all_ne (vector unsigned short, vector bool short); |
| int vec_all_ne (vector unsigned short, vector unsigned short); |
| int vec_all_ne (vector bool short, vector bool short); |
| int vec_all_ne (vector bool short, vector unsigned short); |
| int vec_all_ne (vector bool short, vector signed short); |
| int vec_all_ne (vector pixel, vector pixel); |
| int vec_all_ne (vector signed int, vector bool int); |
| int vec_all_ne (vector signed int, vector signed int); |
| int vec_all_ne (vector unsigned int, vector bool int); |
| int vec_all_ne (vector unsigned int, vector unsigned int); |
| int vec_all_ne (vector bool int, vector bool int); |
| int vec_all_ne (vector bool int, vector unsigned int); |
| int vec_all_ne (vector bool int, vector signed int); |
| int vec_all_ne (vector float, vector float); |
| |
| int vec_all_nge (vector float, vector float); |
| |
| int vec_all_ngt (vector float, vector float); |
| |
| int vec_all_nle (vector float, vector float); |
| |
| int vec_all_nlt (vector float, vector float); |
| |
| int vec_all_numeric (vector float); |
| |
| int vec_any_eq (vector signed char, vector bool char); |
| int vec_any_eq (vector signed char, vector signed char); |
| int vec_any_eq (vector unsigned char, vector bool char); |
| int vec_any_eq (vector unsigned char, vector unsigned char); |
| int vec_any_eq (vector bool char, vector bool char); |
| int vec_any_eq (vector bool char, vector unsigned char); |
| int vec_any_eq (vector bool char, vector signed char); |
| int vec_any_eq (vector signed short, vector bool short); |
| int vec_any_eq (vector signed short, vector signed short); |
| int vec_any_eq (vector unsigned short, vector bool short); |
| int vec_any_eq (vector unsigned short, vector unsigned short); |
| int vec_any_eq (vector bool short, vector bool short); |
| int vec_any_eq (vector bool short, vector unsigned short); |
| int vec_any_eq (vector bool short, vector signed short); |
| int vec_any_eq (vector pixel, vector pixel); |
| int vec_any_eq (vector signed int, vector bool int); |
| int vec_any_eq (vector signed int, vector signed int); |
| int vec_any_eq (vector unsigned int, vector bool int); |
| int vec_any_eq (vector unsigned int, vector unsigned int); |
| int vec_any_eq (vector bool int, vector bool int); |
| int vec_any_eq (vector bool int, vector unsigned int); |
| int vec_any_eq (vector bool int, vector signed int); |
| int vec_any_eq (vector float, vector float); |
| |
| int vec_any_ge (vector signed char, vector bool char); |
| int vec_any_ge (vector unsigned char, vector bool char); |
| int vec_any_ge (vector unsigned char, vector unsigned char); |
| int vec_any_ge (vector signed char, vector signed char); |
| int vec_any_ge (vector bool char, vector unsigned char); |
| int vec_any_ge (vector bool char, vector signed char); |
| int vec_any_ge (vector unsigned short, vector bool short); |
| int vec_any_ge (vector unsigned short, vector unsigned short); |
| int vec_any_ge (vector signed short, vector signed short); |
| int vec_any_ge (vector signed short, vector bool short); |
| int vec_any_ge (vector bool short, vector unsigned short); |
| int vec_any_ge (vector bool short, vector signed short); |
| int vec_any_ge (vector signed int, vector bool int); |
| int vec_any_ge (vector unsigned int, vector bool int); |
| int vec_any_ge (vector unsigned int, vector unsigned int); |
| int vec_any_ge (vector signed int, vector signed int); |
| int vec_any_ge (vector bool int, vector unsigned int); |
| int vec_any_ge (vector bool int, vector signed int); |
| int vec_any_ge (vector float, vector float); |
| |
| int vec_any_gt (vector bool char, vector unsigned char); |
| int vec_any_gt (vector unsigned char, vector bool char); |
| int vec_any_gt (vector unsigned char, vector unsigned char); |
| int vec_any_gt (vector bool char, vector signed char); |
| int vec_any_gt (vector signed char, vector bool char); |
| int vec_any_gt (vector signed char, vector signed char); |
| int vec_any_gt (vector bool short, vector unsigned short); |
| int vec_any_gt (vector unsigned short, vector bool short); |
| int vec_any_gt (vector unsigned short, vector unsigned short); |
| int vec_any_gt (vector bool short, vector signed short); |
| int vec_any_gt (vector signed short, vector bool short); |
| int vec_any_gt (vector signed short, vector signed short); |
| int vec_any_gt (vector bool int, vector unsigned int); |
| int vec_any_gt (vector unsigned int, vector bool int); |
| int vec_any_gt (vector unsigned int, vector unsigned int); |
| int vec_any_gt (vector bool int, vector signed int); |
| int vec_any_gt (vector signed int, vector bool int); |
| int vec_any_gt (vector signed int, vector signed int); |
| int vec_any_gt (vector float, vector float); |
| |
| int vec_any_le (vector bool char, vector unsigned char); |
| int vec_any_le (vector unsigned char, vector bool char); |
| int vec_any_le (vector unsigned char, vector unsigned char); |
| int vec_any_le (vector bool char, vector signed char); |
| int vec_any_le (vector signed char, vector bool char); |
| int vec_any_le (vector signed char, vector signed char); |
| int vec_any_le (vector bool short, vector unsigned short); |
| int vec_any_le (vector unsigned short, vector bool short); |
| int vec_any_le (vector unsigned short, vector unsigned short); |
| int vec_any_le (vector bool short, vector signed short); |
| int vec_any_le (vector signed short, vector bool short); |
| int vec_any_le (vector signed short, vector signed short); |
| int vec_any_le (vector bool int, vector unsigned int); |
| int vec_any_le (vector unsigned int, vector bool int); |
| int vec_any_le (vector unsigned int, vector unsigned int); |
| int vec_any_le (vector bool int, vector signed int); |
| int vec_any_le (vector signed int, vector bool int); |
| int vec_any_le (vector signed int, vector signed int); |
| int vec_any_le (vector float, vector float); |
| |
| int vec_any_lt (vector bool char, vector unsigned char); |
| int vec_any_lt (vector unsigned char, vector bool char); |
| int vec_any_lt (vector unsigned char, vector unsigned char); |
| int vec_any_lt (vector bool char, vector signed char); |
| int vec_any_lt (vector signed char, vector bool char); |
| int vec_any_lt (vector signed char, vector signed char); |
| int vec_any_lt (vector bool short, vector unsigned short); |
| int vec_any_lt (vector unsigned short, vector bool short); |
| int vec_any_lt (vector unsigned short, vector unsigned short); |
| int vec_any_lt (vector bool short, vector signed short); |
| int vec_any_lt (vector signed short, vector bool short); |
| int vec_any_lt (vector signed short, vector signed short); |
| int vec_any_lt (vector bool int, vector unsigned int); |
| int vec_any_lt (vector unsigned int, vector bool int); |
| int vec_any_lt (vector unsigned int, vector unsigned int); |
| int vec_any_lt (vector bool int, vector signed int); |
| int vec_any_lt (vector signed int, vector bool int); |
| int vec_any_lt (vector signed int, vector signed int); |
| int vec_any_lt (vector float, vector float); |
| |
| int vec_any_nan (vector float); |
| |
| int vec_any_ne (vector signed char, vector bool char); |
| int vec_any_ne (vector signed char, vector signed char); |
| int vec_any_ne (vector unsigned char, vector bool char); |
| int vec_any_ne (vector unsigned char, vector unsigned char); |
| int vec_any_ne (vector bool char, vector bool char); |
| int vec_any_ne (vector bool char, vector unsigned char); |
| int vec_any_ne (vector bool char, vector signed char); |
| int vec_any_ne (vector signed short, vector bool short); |
| int vec_any_ne (vector signed short, vector signed short); |
| int vec_any_ne (vector unsigned short, vector bool short); |
| int vec_any_ne (vector unsigned short, vector unsigned short); |
| int vec_any_ne (vector bool short, vector bool short); |
| int vec_any_ne (vector bool short, vector unsigned short); |
| int vec_any_ne (vector bool short, vector signed short); |
| int vec_any_ne (vector pixel, vector pixel); |
| int vec_any_ne (vector signed int, vector bool int); |
| int vec_any_ne (vector signed int, vector signed int); |
| int vec_any_ne (vector unsigned int, vector bool int); |
| int vec_any_ne (vector unsigned int, vector unsigned int); |
| int vec_any_ne (vector bool int, vector bool int); |
| int vec_any_ne (vector bool int, vector unsigned int); |
| int vec_any_ne (vector bool int, vector signed int); |
| int vec_any_ne (vector float, vector float); |
| |
| int vec_any_nge (vector float, vector float); |
| |
| int vec_any_ngt (vector float, vector float); |
| |
| int vec_any_nle (vector float, vector float); |
| |
| int vec_any_nlt (vector float, vector float); |
| |
| int vec_any_numeric (vector float); |
| |
| int vec_any_out (vector float, vector float); |
| |
| If the vector/scalar (VSX) instruction set is available, the following |
| additional functions are available: |
| |
| vector double vec_abs (vector double); |
| vector double vec_add (vector double, vector double); |
| vector double vec_and (vector double, vector double); |
| vector double vec_and (vector double, vector bool long); |
| vector double vec_and (vector bool long, vector double); |
| vector double vec_andc (vector double, vector double); |
| vector double vec_andc (vector double, vector bool long); |
| vector double vec_andc (vector bool long, vector double); |
| vector double vec_ceil (vector double); |
| vector bool long vec_cmpeq (vector double, vector double); |
| vector bool long vec_cmpge (vector double, vector double); |
| vector bool long vec_cmpgt (vector double, vector double); |
| vector bool long vec_cmple (vector double, vector double); |
| vector bool long vec_cmplt (vector double, vector double); |
| vector float vec_div (vector float, vector float); |
| vector double vec_div (vector double, vector double); |
| vector double vec_floor (vector double); |
| vector double vec_ld (int, const vector double *); |
| vector double vec_ld (int, const double *); |
| vector double vec_ldl (int, const vector double *); |
| vector double vec_ldl (int, const double *); |
| vector unsigned char vec_lvsl (int, const volatile double *); |
| vector unsigned char vec_lvsr (int, const volatile double *); |
| vector double vec_madd (vector double, vector double, vector double); |
| vector double vec_max (vector double, vector double); |
| vector double vec_min (vector double, vector double); |
| vector float vec_msub (vector float, vector float, vector float); |
| vector double vec_msub (vector double, vector double, vector double); |
| vector float vec_mul (vector float, vector float); |
| vector double vec_mul (vector double, vector double); |
| vector float vec_nearbyint (vector float); |
| vector double vec_nearbyint (vector double); |
| vector float vec_nmadd (vector float, vector float, vector float); |
| vector double vec_nmadd (vector double, vector double, vector double); |
| vector double vec_nmsub (vector double, vector double, vector double); |
| vector double vec_nor (vector double, vector double); |
| vector double vec_or (vector double, vector double); |
| vector double vec_or (vector double, vector bool long); |
| vector double vec_or (vector bool long, vector double); |
| vector double vec_perm (vector double, |
| vector double, |
| vector unsigned char); |
| vector double vec_rint (vector double); |
| vector double vec_recip (vector double, vector double); |
| vector double vec_rsqrt (vector double); |
| vector double vec_rsqrte (vector double); |
| vector double vec_sel (vector double, vector double, vector bool long); |
| vector double vec_sel (vector double, vector double, vector unsigned long); |
| vector double vec_sub (vector double, vector double); |
| vector float vec_sqrt (vector float); |
| vector double vec_sqrt (vector double); |
| void vec_st (vector double, int, vector double *); |
| void vec_st (vector double, int, double *); |
| vector double vec_trunc (vector double); |
| vector double vec_xor (vector double, vector double); |
| vector double vec_xor (vector double, vector bool long); |
| vector double vec_xor (vector bool long, vector double); |
| int vec_all_eq (vector double, vector double); |
| int vec_all_ge (vector double, vector double); |
| int vec_all_gt (vector double, vector double); |
| int vec_all_le (vector double, vector double); |
| int vec_all_lt (vector double, vector double); |
| int vec_all_nan (vector double); |
| int vec_all_ne (vector double, vector double); |
| int vec_all_nge (vector double, vector double); |
| int vec_all_ngt (vector double, vector double); |
| int vec_all_nle (vector double, vector double); |
| int vec_all_nlt (vector double, vector double); |
| int vec_all_numeric (vector double); |
| int vec_any_eq (vector double, vector double); |
| int vec_any_ge (vector double, vector double); |
| int vec_any_gt (vector double, vector double); |
| int vec_any_le (vector double, vector double); |
| int vec_any_lt (vector double, vector double); |
| int vec_any_nan (vector double); |
| int vec_any_ne (vector double, vector double); |
| int vec_any_nge (vector double, vector double); |
| int vec_any_ngt (vector double, vector double); |
| int vec_any_nle (vector double, vector double); |
| int vec_any_nlt (vector double, vector double); |
| int vec_any_numeric (vector double); |
| |
| vector double vec_vsx_ld (int, const vector double *); |
| vector double vec_vsx_ld (int, const double *); |
| vector float vec_vsx_ld (int, const vector float *); |
| vector float vec_vsx_ld (int, const float *); |
| vector bool int vec_vsx_ld (int, const vector bool int *); |
| vector signed int vec_vsx_ld (int, const vector signed int *); |
| vector signed int vec_vsx_ld (int, const int *); |
| vector signed int vec_vsx_ld (int, const long *); |
| vector unsigned int vec_vsx_ld (int, const vector unsigned int *); |
| vector unsigned int vec_vsx_ld (int, const unsigned int *); |
| vector unsigned int vec_vsx_ld (int, const unsigned long *); |
| vector bool short vec_vsx_ld (int, const vector bool short *); |
| vector pixel vec_vsx_ld (int, const vector pixel *); |
| vector signed short vec_vsx_ld (int, const vector signed short *); |
| vector signed short vec_vsx_ld (int, const short *); |
| vector unsigned short vec_vsx_ld (int, const vector unsigned short *); |
| vector unsigned short vec_vsx_ld (int, const unsigned short *); |
| vector bool char vec_vsx_ld (int, const vector bool char *); |
| vector signed char vec_vsx_ld (int, const vector signed char *); |
| vector signed char vec_vsx_ld (int, const signed char *); |
| vector unsigned char vec_vsx_ld (int, const vector unsigned char *); |
| vector unsigned char vec_vsx_ld (int, const unsigned char *); |
| |
| void vec_vsx_st (vector double, int, vector double *); |
| void vec_vsx_st (vector double, int, double *); |
| void vec_vsx_st (vector float, int, vector float *); |
| void vec_vsx_st (vector float, int, float *); |
| void vec_vsx_st (vector signed int, int, vector signed int *); |
| void vec_vsx_st (vector signed int, int, int *); |
| void vec_vsx_st (vector unsigned int, int, vector unsigned int *); |
| void vec_vsx_st (vector unsigned int, int, unsigned int *); |
| void vec_vsx_st (vector bool int, int, vector bool int *); |
| void vec_vsx_st (vector bool int, int, unsigned int *); |
| void vec_vsx_st (vector bool int, int, int *); |
| void vec_vsx_st (vector signed short, int, vector signed short *); |
| void vec_vsx_st (vector signed short, int, short *); |
| void vec_vsx_st (vector unsigned short, int, vector unsigned short *); |
| void vec_vsx_st (vector unsigned short, int, unsigned short *); |
| void vec_vsx_st (vector bool short, int, vector bool short *); |
| void vec_vsx_st (vector bool short, int, unsigned short *); |
| void vec_vsx_st (vector pixel, int, vector pixel *); |
| void vec_vsx_st (vector pixel, int, unsigned short *); |
| void vec_vsx_st (vector pixel, int, short *); |
| void vec_vsx_st (vector bool short, int, short *); |
| void vec_vsx_st (vector signed char, int, vector signed char *); |
| void vec_vsx_st (vector signed char, int, signed char *); |
| void vec_vsx_st (vector unsigned char, int, vector unsigned char *); |
| void vec_vsx_st (vector unsigned char, int, unsigned char *); |
| void vec_vsx_st (vector bool char, int, vector bool char *); |
| void vec_vsx_st (vector bool char, int, unsigned char *); |
| void vec_vsx_st (vector bool char, int, signed char *); |
| |
| Note that the `vec_ld' and `vec_st' builtins will always generate the |
| Altivec `LVX' and `STVX' instructions even if the VSX instruction set |
| is available. The `vec_vsx_ld' and `vec_vsx_st' builtins will always |
| generate the VSX `LXVD2X', `LXVW4X', `STXVD2X', and `STXVW4X' |
| instructions. |
| |
| GCC provides a few other builtins on Powerpc to access certain |
| instructions: |
| float __builtin_recipdivf (float, float); |
| float __builtin_rsqrtf (float); |
| double __builtin_recipdiv (double, double); |
| double __builtin_rsqrt (double); |
| long __builtin_bpermd (long, long); |
| int __builtin_bswap16 (int); |
| |
| The `vec_rsqrt', `__builtin_rsqrt', and `__builtin_rsqrtf' functions |
| generate multiple instructions to implement the reciprocal sqrt |
| functionality using reciprocal sqrt estimate instructions. |
| |
| The `__builtin_recipdiv', and `__builtin_recipdivf' functions generate |
| multiple instructions to implement division using the reciprocal |
| estimate instructions. |
| |
| |
| File: gcc.info, Node: RX Built-in Functions, Next: SPARC VIS Built-in Functions, Prev: PowerPC AltiVec/VSX Built-in Functions, Up: Target Builtins |
| |
| 6.54.13 RX Built-in Functions |
| ----------------------------- |
| |
| GCC supports some of the RX instructions which cannot be expressed in |
| the C programming language via the use of built-in functions. The |
| following functions are supported: |
| |
| -- Built-in Function: void __builtin_rx_brk (void) |
| Generates the `brk' machine instruction. |
| |
| -- Built-in Function: void __builtin_rx_clrpsw (int) |
| Generates the `clrpsw' machine instruction to clear the specified |
| bit in the processor status word. |
| |
| -- Built-in Function: void __builtin_rx_int (int) |
| Generates the `int' machine instruction to generate an interrupt |
| with the specified value. |
| |
| -- Built-in Function: void __builtin_rx_machi (int, int) |
| Generates the `machi' machine instruction to add the result of |
| multiplying the top 16-bits of the two arguments into the |
| accumulator. |
| |
| -- Built-in Function: void __builtin_rx_maclo (int, int) |
| Generates the `maclo' machine instruction to add the result of |
| multiplying the bottom 16-bits of the two arguments into the |
| accumulator. |
| |
| -- Built-in Function: void __builtin_rx_mulhi (int, int) |
| Generates the `mulhi' machine instruction to place the result of |
| multiplying the top 16-bits of the two arguments into the |
| accumulator. |
| |
| -- Built-in Function: void __builtin_rx_mullo (int, int) |
| Generates the `mullo' machine instruction to place the result of |
| multiplying the bottom 16-bits of the two arguments into the |
| accumulator. |
| |
| -- Built-in Function: int __builtin_rx_mvfachi (void) |
| Generates the `mvfachi' machine instruction to read the top |
| 32-bits of the accumulator. |
| |
| -- Built-in Function: int __builtin_rx_mvfacmi (void) |
| Generates the `mvfacmi' machine instruction to read the middle |
| 32-bits of the accumulator. |
| |
| -- Built-in Function: int __builtin_rx_mvfc (int) |
| Generates the `mvfc' machine instruction which reads the control |
| register specified in its argument and returns its value. |
| |
| -- Built-in Function: void __builtin_rx_mvtachi (int) |
| Generates the `mvtachi' machine instruction to set the top 32-bits |
| of the accumulator. |
| |
| -- Built-in Function: void __builtin_rx_mvtaclo (int) |
| Generates the `mvtaclo' machine instruction to set the bottom |
| 32-bits of the accumulator. |
| |
| -- Built-in Function: void __builtin_rx_mvtc (int reg, int val) |
| Generates the `mvtc' machine instruction which sets control |
| register number `reg' to `val'. |
| |
| -- Built-in Function: void __builtin_rx_mvtipl (int) |
| Generates the `mvtipl' machine instruction set the interrupt |
| priority level. |
| |
| -- Built-in Function: void __builtin_rx_racw (int) |
| Generates the `racw' machine instruction to round the accumulator |
| according to the specified mode. |
| |
| -- Built-in Function: int __builtin_rx_revw (int) |
| Generates the `revw' machine instruction which swaps the bytes in |
| the argument so that bits 0-7 now occupy bits 8-15 and vice versa, |
| and also bits 16-23 occupy bits 24-31 and vice versa. |
| |
| -- Built-in Function: void __builtin_rx_rmpa (void) |
| Generates the `rmpa' machine instruction which initiates a |
| repeated multiply and accumulate sequence. |
| |
| -- Built-in Function: void __builtin_rx_round (float) |
| Generates the `round' machine instruction which returns the |
| floating point argument rounded according to the current rounding |
| mode set in the floating point status word register. |
| |
| -- Built-in Function: int __builtin_rx_sat (int) |
| Generates the `sat' machine instruction which returns the |
| saturated value of the argument. |
| |
| -- Built-in Function: void __builtin_rx_setpsw (int) |
| Generates the `setpsw' machine instruction to set the specified |
| bit in the processor status word. |
| |
| -- Built-in Function: void __builtin_rx_wait (void) |
| Generates the `wait' machine instruction. |
| |
| |
| File: gcc.info, Node: SPARC VIS Built-in Functions, Next: SPU Built-in Functions, Prev: RX Built-in Functions, Up: Target Builtins |
| |
| 6.54.14 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); |
| |
| |
| File: gcc.info, Node: SPU Built-in Functions, Prev: SPARC VIS Built-in Functions, Up: Target Builtins |
| |
| 6.54.15 SPU Built-in Functions |
| ------------------------------ |
| |
| GCC provides extensions for the SPU processor as described in the |
| Sony/Toshiba/IBM SPU Language Extensions Specification, which can be |
| found at `http://cell.scei.co.jp/' or |
| `http://www.ibm.com/developerworks/power/cell/'. GCC's implementation |
| differs in several ways. |
| |
| * The optional extension of specifying vector constants in |
| parentheses is not supported. |
| |
| * A vector initializer requires no cast if the vector constant is of |
| the same type as the variable it is initializing. |
| |
| * If `signed' or `unsigned' is omitted, the signedness of the vector |
| type is the default signedness of the base type. The default |
| varies depending on the operating system, so a portable program |
| should always specify the signedness. |
| |
| * By default, the keyword `__vector' is added. The macro `vector' is |
| defined in `<spu_intrinsics.h>' and can be undefined. |
| |
| * GCC allows using a `typedef' name as the type specifier for a |
| vector type. |
| |
| * For C, overloaded functions are implemented with macros so the |
| following does not work: |
| |
| spu_add ((vector signed int){1, 2, 3, 4}, foo); |
| |
| Since `spu_add' is a macro, the vector constant in the example is |
| treated as four separate arguments. Wrap the entire argument in |
| parentheses for this to work. |
| |
| * The extended version of `__builtin_expect' is not supported. |
| |
| |
| _Note:_ Only the interface described in the aforementioned |
| specification is supported. Internally, GCC uses built-in functions to |
| implement the required functionality, but these are not supported and |
| are subject to change without notice. |
| |
| |
| File: gcc.info, Node: Target Format Checks, Next: Pragmas, Prev: Target Builtins, Up: C Extensions |
| |
| 6.55 Format Checks Specific to Particular Target Machines |
| ========================================================= |
| |
| For some target machines, GCC supports additional options to the format |
| attribute (*note Declaring Attributes of Functions: Function |
| Attributes.). |
| |
| * Menu: |
| |
| * Solaris Format Checks:: |
| * Darwin Format Checks:: |
| |
| |
| File: gcc.info, Node: Solaris Format Checks, Next: Darwin Format Checks, Up: Target Format Checks |
| |
| 6.55.1 Solaris Format Checks |
| ---------------------------- |
| |
| Solaris targets support the `cmn_err' (or `__cmn_err__') format check. |
| `cmn_err' accepts a subset of the standard `printf' conversions, and |
| the two-argument `%b' conversion for displaying bit-fields. See the |
| Solaris man page for `cmn_err' for more information. |
| |
| |
| File: gcc.info, Node: Darwin Format Checks, Prev: Solaris Format Checks, Up: Target Format Checks |
| |
| 6.55.2 Darwin Format Checks |
| --------------------------- |
| |
| Darwin targets support the `CFString' (or `__CFString__') in the format |
| attribute context. Declarations made with such attribution will be |
| parsed for correct syntax and format argument types. However, parsing |
| of the format string itself is currently undefined and will not be |
| carried out by this version of the compiler. |
| |
| Additionally, `CFStringRefs' (defined by the `CoreFoundation' headers) |
| may also be used as format arguments. Note that the relevant headers |
| are only likely to be available on Darwin (OSX) installations. On such |
| installations, the XCode and system documentation provide descriptions |
| of `CFString', `CFStringRefs' and associated functions. |
| |
| |
| File: gcc.info, Node: Pragmas, Next: Unnamed Fields, Prev: Target Format Checks, Up: C Extensions |
| |
| 6.56 Pragmas Accepted by GCC |
| ============================ |
| |
| GCC supports several types of pragmas, primarily in order to compile |
| code originally written for other compilers. Note that in general we |
| do not recommend the use of pragmas; *Note Function Attributes::, for |
| further explanation. |
| |
| * Menu: |
| |
| * ARM Pragmas:: |
| * M32C Pragmas:: |
| * MeP Pragmas:: |
| * RS/6000 and PowerPC Pragmas:: |
| * Darwin Pragmas:: |
| * Solaris Pragmas:: |
| * Symbol-Renaming Pragmas:: |
| * Structure-Packing Pragmas:: |
| * Weak Pragmas:: |
| * Diagnostic Pragmas:: |
| * Visibility Pragmas:: |
| * Push/Pop Macro Pragmas:: |
| * Function Specific Option Pragmas:: |
| |
| |
| File: gcc.info, Node: ARM Pragmas, Next: M32C Pragmas, Up: Pragmas |
| |
| 6.56.1 ARM Pragmas |
| ------------------ |
| |
| The ARM target defines pragmas for controlling the default addition of |
| `long_call' and `short_call' attributes to functions. *Note Function |
| Attributes::, for information about the effects of these attributes. |
| |
| `long_calls' |
| Set all subsequent functions to have the `long_call' attribute. |
| |
| `no_long_calls' |
| Set all subsequent functions to have the `short_call' attribute. |
| |
| `long_calls_off' |
| Do not affect the `long_call' or `short_call' attributes of |
| subsequent functions. |
| |
| |
| File: gcc.info, Node: M32C Pragmas, Next: MeP Pragmas, Prev: ARM Pragmas, Up: Pragmas |
| |
| 6.56.2 M32C Pragmas |
| ------------------- |
| |
| `GCC memregs NUMBER' |
| Overrides the command-line option `-memregs=' for the current |
| file. Use with care! This pragma must be before any function in |
| the file, and mixing different memregs values in different objects |
| may make them incompatible. This pragma is useful when a |
| performance-critical function uses a memreg for temporary values, |
| as it may allow you to reduce the number of memregs used. |
| |
| `ADDRESS NAME ADDRESS' |
| For any declared symbols matching NAME, this does three things to |
| that symbol: it forces the symbol to be located at the given |
| address (a number), it forces the symbol to be volatile, and it |
| changes the symbol's scope to be static. This pragma exists for |
| compatibility with other compilers, but note that the common |
| `1234H' numeric syntax is not supported (use `0x1234' instead). |
| Example: |
| |
| #pragma ADDRESS port3 0x103 |
| char port3; |
| |
| |
| |
| File: gcc.info, Node: MeP Pragmas, Next: RS/6000 and PowerPC Pragmas, Prev: M32C Pragmas, Up: Pragmas |
| |
| 6.56.3 MeP Pragmas |
| ------------------ |
| |
| `custom io_volatile (on|off)' |
| Overrides the command line option `-mio-volatile' for the current |
| file. Note that for compatibility with future GCC releases, this |
| option should only be used once before any `io' variables in each |
| file. |
| |
| `GCC coprocessor available REGISTERS' |
| Specifies which coprocessor registers are available to the register |
| allocator. REGISTERS may be a single register, register range |
| separated by ellipses, or comma-separated list of those. Example: |
| |
| #pragma GCC coprocessor available $c0...$c10, $c28 |
| |
| `GCC coprocessor call_saved REGISTERS' |
| Specifies which coprocessor registers are to be saved and restored |
| by any function using them. REGISTERS may be a single register, |
| register range separated by ellipses, or comma-separated list of |
| those. Example: |
| |
| #pragma GCC coprocessor call_saved $c4...$c6, $c31 |
| |
| `GCC coprocessor subclass '(A|B|C|D)' = REGISTERS' |
| Creates and defines a register class. These register classes can |
| be used by inline `asm' constructs. REGISTERS may be a single |
| register, register range separated by ellipses, or comma-separated |
| list of those. Example: |
| |
| #pragma GCC coprocessor subclass 'B' = $c2, $c4, $c6 |
| |
| asm ("cpfoo %0" : "=B" (x)); |
| |
| `GCC disinterrupt NAME , NAME ...' |
| For the named functions, the compiler adds code to disable |
| interrupts for the duration of those functions. Any functions so |
| named, which are not encountered in the source, cause a warning |
| that the pragma was not used. Examples: |
| |
| #pragma disinterrupt foo |
| #pragma disinterrupt bar, grill |
| int foo () { ... } |
| |
| `GCC call NAME , NAME ...' |
| For the named functions, the compiler always uses a |
| register-indirect call model when calling the named functions. |
| Examples: |
| |
| extern int foo (); |
| #pragma call foo |
| |
| |
| |
| File: gcc.info, Node: RS/6000 and PowerPC Pragmas, Next: Darwin Pragmas, Prev: MeP Pragmas, Up: Pragmas |
| |
| 6.56.4 RS/6000 and PowerPC Pragmas |
| ---------------------------------- |
| |
| The RS/6000 and PowerPC targets define one pragma for controlling |
| whether or not the `longcall' attribute is added to function |
| declarations by default. This pragma overrides the `-mlongcall' |
| option, but not the `longcall' and `shortcall' attributes. *Note |
| RS/6000 and PowerPC Options::, for more information about when long |
| calls are and are not necessary. |
| |
| `longcall (1)' |
| Apply the `longcall' attribute to all subsequent function |
| declarations. |
| |
| `longcall (0)' |
| Do not apply the `longcall' attribute to subsequent function |
| declarations. |
| |
| |
| File: gcc.info, Node: Darwin Pragmas, Next: Solaris Pragmas, Prev: RS/6000 and PowerPC Pragmas, Up: Pragmas |
| |
| 6.56.5 Darwin Pragmas |
| --------------------- |
| |
| The following pragmas are available for all architectures running the |
| Darwin operating system. These are useful for compatibility with other |
| Mac OS compilers. |
| |
| `mark TOKENS...' |
| This pragma is accepted, but has no effect. |
| |
| `options align=ALIGNMENT' |
| This pragma sets the alignment of fields in structures. The |
| values of ALIGNMENT may be `mac68k', to emulate m68k alignment, or |
| `power', to emulate PowerPC alignment. Uses of this pragma nest |
| properly; to restore the previous setting, use `reset' for the |
| ALIGNMENT. |
| |
| `segment TOKENS...' |
| This pragma is accepted, but has no effect. |
| |
| `unused (VAR [, VAR]...)' |
| This pragma declares variables to be possibly unused. GCC 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. |
| |
| |
| File: gcc.info, Node: Solaris Pragmas, Next: Symbol-Renaming Pragmas, Prev: Darwin Pragmas, Up: Pragmas |
| |
| 6.56.6 Solaris Pragmas |
| ---------------------- |
| |
| The Solaris target supports `#pragma redefine_extname' (*note |
| Symbol-Renaming Pragmas::). It also supports additional `#pragma' |
| directives for compatibility with the system compiler. |
| |
| `align ALIGNMENT (VARIABLE [, VARIABLE]...)' |
| Increase the minimum alignment of each VARIABLE to ALIGNMENT. |
| This is the same as GCC's `aligned' attribute *note Variable |
| Attributes::). Macro expansion occurs on the arguments to this |
| pragma when compiling C and Objective-C. It does not currently |
| occur when compiling C++, but this is a bug which may be fixed in |
| a future release. |
| |
| `fini (FUNCTION [, FUNCTION]...)' |
| This pragma causes each listed FUNCTION to be called after main, |
| or during shared module unloading, by adding a call to the `.fini' |
| section. |
| |
| `init (FUNCTION [, FUNCTION]...)' |
| This pragma causes each listed FUNCTION to be called during |
| initialization (before `main') or during shared module loading, by |
| adding a call to the `.init' section. |
| |
| |
| |
| File: gcc.info, Node: Symbol-Renaming Pragmas, Next: Structure-Packing Pragmas, Prev: Solaris Pragmas, Up: Pragmas |
| |
| 6.56.7 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. `#pragma extern_prefix' is only |
| available on platforms whose system headers need it. 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 on all |
| platforms). |
| |
| `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.) |
| |
| |
| File: gcc.info, Node: Structure-Packing Pragmas, Next: Weak Pragmas, Prev: Symbol-Renaming Pragmas, Up: Pragmas |
| |
| 6.56.8 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. |
| |
| |
| File: gcc.info, Node: Weak Pragmas, Next: Diagnostic Pragmas, Prev: Structure-Packing Pragmas, Up: Pragmas |
| |
| 6.56.9 Weak Pragmas |
| ------------------- |
| |
| For compatibility with SVR4, GCC supports a set of `#pragma' directives |
| for declaring symbols to be weak, and defining weak aliases. |
| |
| `#pragma weak SYMBOL' |
| This pragma declares SYMBOL to be weak, as if the declaration had |
| the attribute of the same name. The pragma may appear before or |
| after the declaration of SYMBOL. It is not an error for SYMBOL to |
| never be defined at all. |
| |
| `#pragma weak SYMBOL1 = SYMBOL2' |
| This pragma declares SYMBOL1 to be a weak alias of SYMBOL2. It is |
| an error if SYMBOL2 is not defined in the current translation unit. |
| |
| |
| File: gcc.info, Node: Diagnostic Pragmas, Next: Visibility Pragmas, Prev: Weak Pragmas, Up: Pragmas |
| |
| 6.56.10 Diagnostic Pragmas |
| -------------------------- |
| |
| GCC allows the user to selectively enable or disable certain types of |
| diagnostics, and change the kind of the diagnostic. For example, a |
| project's policy might require that all sources compile with `-Werror' |
| but certain files might have exceptions allowing specific types of |
| warnings. Or, a project might selectively enable diagnostics and treat |
| them as errors depending on which preprocessor macros are defined. |
| |
| `#pragma GCC diagnostic KIND OPTION' |
| Modifies the disposition of a diagnostic. Note that not all |
| diagnostics are modifiable; at the moment only warnings (normally |
| controlled by `-W...') can be controlled, and not all of them. |
| Use `-fdiagnostics-show-option' to determine which diagnostics are |
| controllable and which option controls them. |
| |
| KIND is `error' to treat this diagnostic as an error, `warning' to |
| treat it like a warning (even if `-Werror' is in effect), or |
| `ignored' if the diagnostic is to be ignored. OPTION is a double |
| quoted string 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. GCC |
| keeps track of the location of each pragma, and issues diagnostics |
| according to the state as of that point in the source file. Thus, |
| pragmas occurring after a line do not affect diagnostics caused by |
| that line. |
| |
| `#pragma GCC diagnostic push' |
| `#pragma GCC diagnostic pop' |
| Causes GCC to remember the state of the diagnostics as of each |
| `push', and restore to that point at each `pop'. If a `pop' has |
| no matching `push', the command line options are restored. |
| |
| #pragma GCC diagnostic error "-Wuninitialized" |
| foo(a); /* error is given for this one */ |
| #pragma GCC diagnostic push |
| #pragma GCC diagnostic ignored "-Wuninitialized" |
| foo(b); /* no diagnostic for this one */ |
| #pragma GCC diagnostic pop |
| foo(c); /* error is given for this one */ |
| #pragma GCC diagnostic pop |
| foo(d); /* depends on command line options */ |
| |
| |
| GCC also offers a simple mechanism for printing messages during |
| compilation. |
| |
| `#pragma message STRING' |
| Prints STRING as a compiler message on compilation. The message |
| is informational only, and is neither a compilation warning nor an |
| error. |
| |
| #pragma message "Compiling " __FILE__ "..." |
| |
| STRING may be parenthesized, and is printed with location |
| information. For example, |
| |
| #define DO_PRAGMA(x) _Pragma (#x) |
| #define TODO(x) DO_PRAGMA(message ("TODO - " #x)) |
| |
| TODO(Remember to fix this) |
| |
| prints `/tmp/file.c:4: note: #pragma message: TODO - Remember to |
| fix this'. |
| |
| |
| |
| File: gcc.info, Node: Visibility Pragmas, Next: Push/Pop Macro Pragmas, Prev: Diagnostic Pragmas, Up: Pragmas |
| |
| 6.56.11 Visibility Pragmas |
| -------------------------- |
| |
| `#pragma GCC visibility push(VISIBILITY)' |
| `#pragma GCC visibility pop' |
| This pragma allows the user to set the visibility for multiple |
| declarations without having to give each a visibility attribute |
| *Note Function Attributes::, for more information about visibility |
| and the attribute syntax. |
| |
| In C++, `#pragma GCC visibility' affects only namespace-scope |
| declarations. Class members and template specializations are not |
| affected; if you want to override the visibility for a particular |
| member or instantiation, you must use an attribute. |
| |
| |
| |
| File: gcc.info, Node: Push/Pop Macro Pragmas, Next: Function Specific Option Pragmas, Prev: Visibility Pragmas, Up: Pragmas |
| |
| 6.56.12 Push/Pop Macro Pragmas |
| ------------------------------ |
| |
| For compatibility with Microsoft Windows compilers, GCC supports |
| `#pragma push_macro("MACRO_NAME")' and `#pragma |
| pop_macro("MACRO_NAME")'. |
| |
| `#pragma push_macro("MACRO_NAME")' |
| This pragma saves the value of the macro named as MACRO_NAME to |
| the top of the stack for this macro. |
| |
| `#pragma pop_macro("MACRO_NAME")' |
| This pragma sets the value of the macro named as MACRO_NAME to the |
| value on top of the stack for this macro. If the stack for |
| MACRO_NAME is empty, the value of the macro remains unchanged. |
| |
| For example: |
| |
| #define X 1 |
| #pragma push_macro("X") |
| #undef X |
| #define X -1 |
| #pragma pop_macro("X") |
| int x [X]; |
| |
| In this example, the definition of X as 1 is saved by `#pragma |
| push_macro' and restored by `#pragma pop_macro'. |
| |
| |
| File: gcc.info, Node: Function Specific Option Pragmas, Prev: Push/Pop Macro Pragmas, Up: Pragmas |
| |
| 6.56.13 Function Specific Option Pragmas |
| ---------------------------------------- |
| |
| `#pragma GCC target ("STRING"...)' |
| This pragma allows you to set target specific options for functions |
| defined later in the source file. One or more strings can be |
| specified. Each function that is defined after this point 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' attribute is not implemented in GCC |
| versions earlier than 4.4 for the i386/x86_64 and 4.6 for the |
| PowerPC backends. At present, it is not implemented for other |
| 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. |
| |
| |
| File: gcc.info, Node: Unnamed Fields, Next: Thread-Local, Prev: Pragmas, Up: C Extensions |
| |
| 6.57 Unnamed struct/union fields within structs/unions |
| ====================================================== |
| |
| As permitted by ISO C1X and for compatibility with other compilers, GCC |
| allows you to define a structure or union that contains, as fields, |
| structures and unions without names. For example: |
| |
| struct { |
| int a; |
| union { |
| int b; |
| float c; |
| }; |
| int d; |
| } foo; |
| |
| In this example, 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'. The |
| compiler gives errors for such constructs. |
| |
| Unless `-fms-extensions' is used, the unnamed field must be a |
| structure or union definition without a tag (for example, `struct { int |
| a; };'). If `-fms-extensions' is used, the field may also be a |
| definition with a tag such as `struct foo { int a; };', a reference to |
| a previously defined structure or union such as `struct foo;', or a |
| reference to a `typedef' name for a previously defined structure or |
| union type. |
| |
| The option `-fplan9-extensions' enables `-fms-extensions' as well as |
| two other extensions. First, a pointer to a structure is automatically |
| converted to a pointer to an anonymous field for assignments and |
| function calls. For example: |
| |
| struct s1 { int a; }; |
| struct s2 { struct s1; }; |
| extern void f1 (struct s1 *); |
| void f2 (struct s2 *p) { f1 (p); } |
| |
| In the call to `f1' inside `f2', the pointer `p' is converted into a |
| pointer to the anonymous field. |
| |
| Second, when the type of an anonymous field is a `typedef' for a |
| `struct' or `union', code may refer to the field using the name of the |
| `typedef'. |
| |
| typedef struct { int a; } s1; |
| struct s2 { s1; }; |
| s1 f1 (struct s2 *p) { return p->s1; } |
| |
| These usages are only permitted when they are not ambiguous. |
| |
| |
| File: gcc.info, Node: Thread-Local, Next: Binary constants, Prev: Unnamed Fields, Up: C Extensions |
| |
| 6.58 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://www.akkadia.org/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:: |
| |
| |
| File: gcc.info, Node: C99 Thread-Local Edits, Next: C++98 Thread-Local Edits, Up: Thread-Local |
| |
| 6.58.1 ISO/IEC 9899:1999 Edits for Thread-Local Storage |
| ------------------------------------------------------- |
| |
| The following are a set of changes to ISO/IEC 9899:1999 (aka C99) that |
| document the exact semantics of the language extension. |
| |
| * `5.1.2 Execution environments' |
| |
| Add new text after paragraph 1 |
| |
| Within either execution environment, a "thread" is a flow of |
| control within a program. It is implementation defined |
| whether or not there may be more than one thread associated |
| with a program. It is implementation defined how threads |
| beyond the first are created, the name and type of the |
| function called at thread startup, and how threads may be |
| terminated. However, objects with thread storage duration |
| shall be initialized before thread startup. |
| |
| * `6.2.4 Storage durations of objects' |
| |
| Add new text before paragraph 3 |
| |
| An object whose identifier is declared with the storage-class |
| specifier `__thread' has "thread storage duration". Its |
| lifetime is the entire execution of the thread, and its |
| stored value is initialized only once, prior to thread |
| startup. |
| |
| * `6.4.1 Keywords' |
| |
| Add `__thread'. |
| |
| * `6.7.1 Storage-class specifiers' |
| |
| Add `__thread' to the list of storage class specifiers in |
| paragraph 1. |
| |
| Change paragraph 2 to |
| |
| With the exception of `__thread', at most one storage-class |
| specifier may be given [...]. The `__thread' specifier may |
| be used alone, or immediately following `extern' or `static'. |
| |
| Add new text after paragraph 6 |
| |
| The declaration of an identifier for a variable that has |
| block scope that specifies `__thread' shall also specify |
| either `extern' or `static'. |
| |
| The `__thread' specifier shall be used only with variables. |
| |
| |
| File: gcc.info, Node: C++98 Thread-Local Edits, Prev: C99 Thread-Local Edits, Up: Thread-Local |
| |
| 6.58.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'. |
| |
| |
| File: gcc.info, Node: Binary constants, Prev: Thread-Local, Up: C Extensions |
| |
| 6.59 Binary constants using the `0b' prefix |
| =========================================== |
| |
| Integer constants can be written as binary constants, consisting of a |
| sequence of `0' and `1' digits, prefixed by `0b' or `0B'. This is |
| particularly useful in environments that operate a lot on the bit-level |
| (like microcontrollers). |
| |
| The following statements are identical: |
| |
| i = 42; |
| i = 0x2a; |
| i = 052; |
| i = 0b101010; |
| |
| The type of these constants follows the same rules as for octal or |
| hexadecimal integer constants, so suffixes like `L' or `UL' can be |
| applied. |
| |
| |
| File: gcc.info, Node: C++ Extensions, Next: Objective-C, Prev: C++ Implementation, Up: Top |
| |
| 7 Extensions to the C++ Language |
| ******************************** |
| |
| The GNU compiler provides these extensions to the C++ language (and you |
| can also use most of the C language extensions in your C++ programs). |
| If you want to write code that checks whether these features are |
| available, you can test for the GNU compiler the same way as for C |
| programs: check for a predefined macro `__GNUC__'. You can also use |
| `__GNUG__' to test specifically for GNU C++ (*note Predefined Macros: |
| (cpp)Common Predefined Macros.). |
| |
| * Menu: |
| |
| * C++ Volatiles:: What constitutes an access to a volatile object. |
| * Restricted Pointers:: C99 restricted pointers and references. |
| * Vague Linkage:: Where G++ puts inlines, vtables and such. |
| * C++ Interface:: You can use a single C++ header file for both |
| declarations and definitions. |
| * Template Instantiation:: Methods for ensuring that exactly one copy of |
| each needed template instantiation is emitted. |
| * Bound member functions:: You can extract a function pointer to the |
| method denoted by a `->*' or `.*' expression. |
| * C++ Attributes:: Variable, function, and type attributes for C++ only. |
| * Namespace Association:: Strong using-directives for namespace association. |
| * Type Traits:: Compiler support for type traits |
| * Java Exceptions:: Tweaking exception handling to work with Java. |
| * Deprecated Features:: Things will disappear from g++. |
| * Backwards Compatibility:: Compatibilities with earlier definitions of C++. |
| |
| |
| File: gcc.info, Node: C++ Volatiles, Next: Restricted Pointers, Up: C++ Extensions |
| |
| 7.1 When is a Volatile C++ Object Accessed? |
| =========================================== |
| |
| The C++ standard differs from the C standard in its treatment of |
| volatile objects. It fails to specify what constitutes a volatile |
| access, except to say that C++ should behave in a similar manner to C |
| with respect to volatiles, where possible. However, the different |
| lvalueness of expressions between C and C++ complicate the behavior. |
| G++ behaves the same as GCC for volatile access, *Note Volatiles: C |
| Extensions, for a description of GCC's behavior. |
| |
| The C and C++ language specifications differ when an object is |
| accessed in a void context: |
| |
| volatile int *src = SOMEVALUE; |
| *src; |
| |
| The C++ standard specifies that such expressions do not undergo lvalue |
| to rvalue conversion, and that the type of the dereferenced object may |
| be incomplete. The C++ standard does not specify explicitly that it is |
| lvalue to rvalue conversion which is responsible for causing an access. |
| There is reason to believe that it is, because otherwise certain simple |
| expressions become undefined. However, because it would surprise most |
| programmers, G++ treats dereferencing a pointer to volatile object of |
| complete type as GCC would do for an equivalent type in C. When the |
| object has incomplete type, G++ issues a warning; if you wish to force |
| an error, you must force a conversion to rvalue with, for instance, a |
| static cast. |
| |
| When using a reference to volatile, G++ does not treat equivalent |
| expressions as accesses to volatiles, but instead issues a warning that |
| no volatile is accessed. The rationale for this is that otherwise it |
| becomes difficult to determine where volatile access occur, and not |
| possible to ignore the return value from functions returning volatile |
| references. Again, if you wish to force a read, cast the reference to |
| an rvalue. |
| |
| G++ implements the same behavior as GCC does when assigning to a |
| volatile object - there is no reread of the assigned-to object, the |
| assigned rvalue is reused. Note that in C++ assignment expressions are |
| lvalues, and if used as an lvalue, the volatile object will be referred |
| to. For instance, VREF will refer to VOBJ, as expected, in the |
| following example: |
| |
| volatile int vobj; |
| volatile int &vref = vobj = SOMETHING; |
| |
| |
| File: gcc.info, Node: Restricted Pointers, Next: Vague Linkage, Prev: C++ Volatiles, Up: C++ Extensions |
| |
| 7.2 Restricting Pointer Aliasing |
| ================================ |
| |
| As with the C front end, G++ understands the C99 feature of restricted |
| pointers, specified with the `__restrict__', or `__restrict' type |
| qualifier. Because you cannot compile C++ by specifying the `-std=c99' |
| language flag, `restrict' is not a keyword in C++. |
| |
| In addition to allowing restricted pointers, you can specify restricted |
| references, which indicate that the reference is not aliased in the |
| local context. |
| |
| void fn (int *__restrict__ rptr, int &__restrict__ rref) |
| { |
| /* ... */ |
| } |
| |
| In the body of `fn', RPTR points to an unaliased integer and RREF |
| refers to a (different) unaliased integer. |
| |
| You may also specify whether a member function's THIS pointer is |
| unaliased by using `__restrict__' as a member function qualifier. |
| |
| void T::fn () __restrict__ |
| { |
| /* ... */ |
| } |
| |
| Within the body of `T::fn', THIS 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. |
| |
| |
| File: gcc.info, Node: Vague Linkage, Next: C++ Interface, Prev: Restricted Pointers, Up: C++ Extensions |
| |
| 7.3 Vague Linkage |
| ================= |
| |
| There are several constructs in C++ 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. |
| |
| |
| File: gcc.info, Node: C++ Interface, Next: Template Instantiation, Prev: Vague Linkage, Up: C++ Extensions |
| |
| 7.4 #pragma interface and implementation |
| ======================================== |
| |
| `#pragma interface' and `#pragma implementation' provide the user with |
| a way of explicitly directing the compiler to emit entities with vague |
| linkage (and debugging information) in a particular translation unit. |
| |
| _Note:_ As of GCC 2.7.2, these `#pragma's are not useful in most |
| cases, because of COMDAT support and the "key method" heuristic |
| mentioned in *note Vague Linkage::. Using them can actually cause your |
| program to grow due to unnecessary out-of-line copies of inline |
| functions. Currently (3.4) the only benefit of these `#pragma's is |
| reduced duplication of debugging information, and that should be |
| addressed soon on DWARF 2 targets with the use of COMDAT groups. |
| |
| `#pragma interface' |
| `#pragma interface "SUBDIR/OBJECTS.h"' |
| Use this directive in _header files_ that define object classes, |
| to save space in most of the object files that use those classes. |
| Normally, local copies of certain information (backup copies of |
| inline member functions, debugging information, and the internal |
| tables that implement virtual functions) must be kept in each |
| object file that includes class definitions. You can use this |
| pragma to avoid such duplication. When a header file containing |
| `#pragma interface' is included in a compilation, this auxiliary |
| information 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'. |
| |
| |
| File: gcc.info, Node: Template Instantiation, Next: Bound member functions, Prev: C++ Interface, Up: C++ Extensions |
| |
| 7.5 Where's the Template? |
| ========================= |
| |
| C++ templates are the first language feature to require more |
| intelligence from the environment than one usually finds on a UNIX |
| system. Somehow the compiler and linker have to make sure that each |
| template instance occurs exactly once in the executable if it is needed, |
| and not at all otherwise. There are two basic approaches to this |
| problem, which are referred to as the Borland model and the Cfront |
| model. |
| |
| Borland model |
| Borland C++ solved the template instantiation problem by adding |
| the code equivalent of common blocks to their linker; the compiler |
| emits template instances in each translation unit that uses them, |
| and the linker collapses them together. The advantage of this |
| model is that the linker only has to consider the object files |
| themselves; there is no external complexity to worry about. This |
| disadvantage is that compilation time is increased because the |
| template code is being compiled repeatedly. Code written for this |
| model tends to include definitions of all templates in the header |
| file, since they must be seen to be instantiated. |
| |
| Cfront model |
| The AT&T C++ translator, Cfront, solved the template instantiation |
| problem by creating the notion of a template repository, an |
| automatically maintained place where template instances are |
| stored. A more modern version of the repository works as follows: |
| As individual object files are built, the compiler places any |
| template definitions and instantiations encountered in the |
| repository. At link time, the link wrapper adds in the objects in |
| the repository and compiles any needed instances that were not |
| previously emitted. The advantages of this model are more optimal |
| compilation speed and the ability to use the system linker; to |
| implement the Borland model a compiler vendor also needs to |
| replace the linker. The disadvantages are vastly increased |
| complexity, and thus potential for error; for some code this can be |
| just as transparent, but in practice it can been very difficult to |
| build multiple programs in one directory and one program in |
| multiple directories. Code written for this model tends to |
| separate definitions of non-inline member templates into a |
| separate file, which should be compiled separately. |
| |
| When used with GNU ld version 2.8 or later on an ELF system such as |
| GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the |
| Borland model. On other systems, G++ implements neither automatic |
| model. |
| |
| 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. |
| |
| |
| File: gcc.info, Node: Bound member functions, Next: C++ Attributes, Prev: Template Instantiation, Up: C++ Extensions |
| |
| 7.6 Extracting the function pointer from a bound pointer to member function |
| =========================================================================== |
| |
| In C++, pointer to member functions (PMFs) are implemented using a wide |
| pointer of sorts to handle all the possible call mechanisms; the PMF |
| needs to store information about how to adjust the `this' pointer, and |
| if the function pointed to is virtual, where to find the vtable, and |
| where in the vtable to look for the member function. If you are using |
| PMFs in an inner loop, you should really reconsider that decision. If |
| that is not an option, you can extract the pointer to the function that |
| would be called for a given object/PMF pair and call it directly inside |
| the inner loop, to save a bit of time. |
| |
| Note that you 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. |
| |
| |
| File: gcc.info, Node: C++ Attributes, Next: Namespace Association, Prev: Bound member functions, Up: C++ Extensions |
| |
| 7.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::. |
| |
| |
| File: gcc.info, Node: Namespace Association, Next: Type Traits, Prev: C++ Attributes, Up: C++ Extensions |
| |
| 7.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>()); |
| } |
| |
| |
| File: gcc.info, Node: Type Traits, Next: Java Exceptions, Prev: Namespace Association, Up: C++ Extensions |
| |
| 7.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, (possibly cv-qualified) `void', or an array of |
| unknown bound. |
| |
| `__has_nothrow_copy (type)' |
| If `__has_trivial_copy (type)' is true then the trait is true, |
| else if `type' is a cv class or union type with copy constructors |
| that are known not to throw an exception then the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__has_nothrow_constructor (type)' |
| If `__has_trivial_constructor (type)' is true then the trait is |
| true, else if `type' is a cv class or union type (or array |
| thereof) with a default constructor that is known not to throw an |
| exception then the trait is true, else it is false. Requires: |
| `type' shall be a complete type, (possibly cv-qualified) `void', |
| or an array of unknown bound. |
| |
| `__has_trivial_assign (type)' |
| If `type' is const qualified or is a reference type then the trait |
| is false. Otherwise if `__is_pod (type)' is true then the trait is |
| true, else if `type' is a cv class or union type with a trivial |
| copy assignment ([class.copy]) then the trait is true, else it is |
| false. Requires: `type' shall be a complete type, (possibly |
| cv-qualified) `void', or an array of unknown bound. |
| |
| `__has_trivial_copy (type)' |
| If `__is_pod (type)' is true or `type' is a reference type then |
| the trait is true, else if `type' is a cv class or union type with |
| a trivial copy constructor ([class.copy]) then the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__has_trivial_constructor (type)' |
| If `__is_pod (type)' is true then the trait is true, else if |
| `type' is a cv class or union type (or array thereof) with a |
| trivial default constructor ([class.ctor]) then the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__has_trivial_destructor (type)' |
| If `__is_pod (type)' is true or `type' is a reference type then |
| the trait is true, else if `type' is a cv class or union type (or |
| array thereof) with a trivial destructor ([class.dtor]) then the |
| trait is true, else it is false. Requires: `type' shall be a |
| complete type, (possibly cv-qualified) `void', or an array of |
| unknown bound. |
| |
| `__has_virtual_destructor (type)' |
| If `type' is a class type with a virtual destructor ([class.dtor]) |
| then the trait is true, else it is false. Requires: `type' shall |
| be a complete type, (possibly cv-qualified) `void', or an array of |
| unknown bound. |
| |
| `__is_abstract (type)' |
| If `type' is an abstract class ([class.abstract]) then the trait |
| is true, else it is false. Requires: `type' shall be a complete |
| type, (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_base_of (base_type, derived_type)' |
| If `base_type' is a base class of `derived_type' ([class.derived]) |
| then the trait is true, otherwise it is false. Top-level cv |
| qualifications of `base_type' and `derived_type' are ignored. For |
| the purposes of this trait, a class type is considered is own |
| base. Requires: if `__is_class (base_type)' and `__is_class |
| (derived_type)' are true and `base_type' and `derived_type' are |
| not the same type (disregarding cv-qualifiers), `derived_type' |
| shall be a complete type. Diagnostic is produced if this |
| requirement is not met. |
| |
| `__is_class (type)' |
| If `type' is a cv class type, and not a union type |
| ([basic.compound]) the trait is true, else it is false. |
| |
| `__is_empty (type)' |
| If `__is_class (type)' is false then the trait is false. |
| Otherwise `type' is considered empty if and only if: `type' has no |
| non-static data members, or all non-static data members, if any, |
| are bit-fields of length 0, and `type' has no virtual members, and |
| `type' has no virtual base classes, and `type' has no base classes |
| `base_type' for which `__is_empty (base_type)' is false. |
| Requires: `type' shall be a complete type, (possibly cv-qualified) |
| `void', or an array of unknown bound. |
| |
| `__is_enum (type)' |
| If `type' is a cv enumeration type ([basic.compound]) the trait is |
| true, else it is false. |
| |
| `__is_literal_type (type)' |
| If `type' is a literal type ([basic.types]) the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_pod (type)' |
| If `type' is a cv POD type ([basic.types]) then the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_polymorphic (type)' |
| If `type' is a polymorphic class ([class.virtual]) then the trait |
| is true, else it is false. Requires: `type' shall be a complete |
| type, (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_standard_layout (type)' |
| If `type' is a standard-layout type ([basic.types]) the trait is |
| true, else it is false. Requires: `type' shall be a complete |
| type, (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_trivial (type)' |
| If `type' is a trivial type ([basic.types]) the trait is true, |
| else it is false. Requires: `type' shall be a complete type, |
| (possibly cv-qualified) `void', or an array of unknown bound. |
| |
| `__is_union (type)' |
| If `type' is a cv union type ([basic.compound]) the trait is true, |
| else it is false. |
| |
| |
| |
| File: gcc.info, Node: Java Exceptions, Next: Deprecated Features, Prev: Type Traits, Up: C++ Extensions |
| |
| 7.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. |
| |
| |
| File: gcc.info, Node: Deprecated Features, Next: Backwards Compatibility, Prev: Java Exceptions, Up: C++ Extensions |
| |
| 7.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. |
| |
| |
| File: gcc.info, Node: Backwards Compatibility, Prev: Deprecated Features, Up: C++ Extensions |
| |
| 7.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. |
| |
| |
| File: gcc.info, Node: Objective-C, Next: Compatibility, Prev: C++ Extensions, Up: Top |
| |
| 8 GNU Objective-C features |
| ************************** |
| |
| This document is meant to describe some of the GNU Objective-C |
| features. It is not intended to teach you Objective-C. There are |
| several resources on the Internet that present the language. |
| |
| * Menu: |
| |
| * GNU Objective-C runtime API:: |
| * Executing code before main:: |
| * Type encoding:: |
| * Garbage Collection:: |
| * Constant string objects:: |
| * compatibility_alias:: |
| * Exceptions:: |
| * Synchronization:: |
| * Fast enumeration:: |
| * Messaging with the GNU Objective-C runtime:: |
| |
| |
| File: gcc.info, Node: GNU Objective-C runtime API, Next: Executing code before main, Up: Objective-C |
| |
| 8.1 GNU Objective-C runtime API |
| =============================== |
| |
| This section is specific for the GNU Objective-C runtime. If you are |
| using a different runtime, you can skip it. |
| |
| The GNU Objective-C runtime provides an API that allows you to |
| interact with the Objective-C runtime system, querying the live runtime |
| structures and even manipulating them. This allows you for example to |
| inspect and navigate classes, methods and protocols; to define new |
| classes or new methods, and even to modify existing classes or |
| protocols. |
| |
| If you are using a "Foundation" library such as GNUstep-Base, this |
| library will provide you with a rich set of functionality to do most of |
| the inspection tasks, and you probably will only need direct access to |
| the GNU Objective-C runtime API to define new classes or methods. |
| |
| * Menu: |
| |
| * Modern GNU Objective-C runtime API:: |
| * Traditional GNU Objective-C runtime API:: |
| |
| |
| File: gcc.info, Node: Modern GNU Objective-C runtime API, Next: Traditional GNU Objective-C runtime API, Up: GNU Objective-C runtime API |
| |
| 8.1.1 Modern GNU Objective-C runtime API |
| ---------------------------------------- |
| |
| The GNU Objective-C runtime provides an API which is similar to the one |
| provided by the "Objective-C 2.0" Apple/NeXT Objective-C runtime. The |
| API is documented in the public header files of the GNU Objective-C |
| runtime: |
| |
| * `objc/objc.h': this is the basic Objective-C header file, defining |
| the basic Objective-C types such as `id', `Class' and `BOOL'. You |
| have to include this header to do almost anything with Objective-C. |
| |
| * `objc/runtime.h': this header declares most of the public runtime |
| API functions allowing you to inspect and manipulate the |
| Objective-C runtime data structures. These functions are fairly |
| standardized across Objective-C runtimes and are almost identical |
| to the Apple/NeXT Objective-C runtime ones. It does not declare |
| functions in some specialized areas (constructing and forwarding |
| message invocations, threading) which are in the other headers |
| below. You have to include `objc/objc.h' and `objc/runtime.h' to |
| use any of the functions, such as `class_getName()', declared in |
| `objc/runtime.h'. |
| |
| * `objc/message.h': this header declares public functions used to |
| construct, deconstruct and forward message invocations. Because |
| messaging is done in quite a different way on different runtimes, |
| functions in this header are specific to the GNU Objective-C |
| runtime implementation. |
| |
| * `objc/objc-exception.h': this header declares some public |
| functions related to Objective-C exceptions. For example |
| functions in this header allow you to throw an Objective-C |
| exception from plain C/C++ code. |
| |
| * `objc/objc-sync.h': this header declares some public functions |
| related to the Objective-C `@synchronized()' syntax, allowing you |
| to emulate an Objective-C `@synchronized()' block in plain C/C++ |
| code. |
| |
| * `objc/thr.h': this header declares a public runtime API threading |
| layer that is only provided by the GNU Objective-C runtime. It |
| declares functions such as `objc_mutex_lock()', which provide a |
| platform-independent set of threading functions. |
| |
| |
| The header files contain detailed documentation for each function in |
| the GNU Objective-C runtime API. |
| |
| |
| File: gcc.info, Node: Traditional GNU Objective-C runtime API, Prev: Modern GNU Objective-C runtime API, Up: GNU Objective-C runtime API |
| |
| 8.1.2 Traditional GNU Objective-C runtime API |
| --------------------------------------------- |
| |
| The GNU Objective-C runtime used to provide a different API, which we |
| call the "traditional" GNU Objective-C runtime API. Functions |
| belonging to this API are easy to recognize because they use a |
| different naming convention, such as `class_get_super_class()' |
| (traditional API) instead of `class_getSuperclass()' (modern API). |
| Software using this API includes the file `objc/objc-api.h' where it is |
| declared. |
| |
| The traditional API is deprecated but it is still supported in this |
| release of the runtime; you can access it as usual by including |
| `objc/objc-api.h'. |
| |
| If you are using the traditional API you are urged to upgrade your |
| software to use the modern API because the traditional API requires |
| access to private runtime internals to do anything serious with it; for |
| this reason, there is no guarantee that future releases of the GNU |
| Objective-C runtime library will be able to provide a fully compatible |
| `objc/objc-api.h' as the private runtime internals change. It is |
| expected that the next release will hide a number of runtime internals |
| making the traditional API nominally supported but fairly useless |
| beyond very simple use cases. |
| |
| Finally, you can not include both `objc/objc-api.h' and |
| `objc/runtime.h' at the same time. The traditional and modern APIs |
| unfortunately have some conflicting declarations (such as the one for |
| `Method') and can not be used at the same time. |
| |
| |
| File: gcc.info, Node: Executing code before main, Next: Type encoding, Prev: GNU Objective-C runtime API, Up: Objective-C |
| |
| 8.2 `+load': Executing code before main |
| ======================================= |
| |
| This section is specific for the GNU Objective-C runtime. If you are |
| using a different runtime, you can skip it. |
| |
| The GNU Objective-C runtime provides a way that allows you to execute |
| code before the execution of the program enters the `main' function. |
| The code is executed on a per-class and a per-category basis, through a |
| special class method `+load'. |
| |
| This facility is very useful if you want to initialize global variables |
| which can be accessed by the program directly, without sending a message |
| to the class first. The usual way to initialize global variables, in |
| the `+initialize' method, might not be useful because `+initialize' is |
| only called when the first message is sent to a class object, which in |
| some cases could be too late. |
| |
| Suppose for example you have a `FileStream' class that declares |
| `Stdin', `Stdout' and `Stderr' as global variables, like below: |
| |
| |
| FileStream *Stdin = nil; |
| FileStream *Stdout = nil; |
| FileStream *Stderr = nil; |
| |
| @implementation FileStream |
| |
| + (void)initialize |
| { |
| Stdin = [[FileStream new] initWithFd:0]; |
| Stdout = [[FileStream new] initWithFd:1]; |
| Stderr = [[FileStream new] initWithFd:2]; |
| } |
| |
| /* Other methods here */ |
| @end |
| |
| In this example, the initialization of `Stdin', `Stdout' and `Stderr' |
| in `+initialize' occurs too late. The programmer can send a message to |
| one of these objects before the variables are actually initialized, |
| thus sending messages to the `nil' object. The `+initialize' method |
| which actually initializes the global variables is not invoked until |
| the first message is sent to the class object. The solution would |
| require these variables to be initialized just before entering `main'. |
| |
| The correct solution of the above problem is to use the `+load' method |
| instead of `+initialize': |
| |
| |
| @implementation FileStream |
| |
| + (void)load |
| { |
| Stdin = [[FileStream new] initWithFd:0]; |
| Stdout = [[FileStream new] initWithFd:1]; |
| Stderr = [[FileStream new] initWithFd:2]; |
| } |
| |
| /* Other methods here */ |
| @end |
| |
| The `+load' is a method that is not overridden by categories. If a |
| class and a category of it both implement `+load', both methods are |
| invoked. This allows some additional initializations to be performed in |
| a category. |
| |
| This mechanism is not intended to be a replacement for `+initialize'. |
| You should be aware of its limitations when you decide to use it |
| instead of `+initialize'. |
| |
| * Menu: |
| |
| * What you can and what you cannot do in +load:: |
| |
| |
| File: gcc.info, Node: What you can and what you cannot do in +load, Up: Executing code before main |
| |
| 8.2.1 What you can and what you cannot do in `+load' |
| ---------------------------------------------------- |
| |
| `+load' is to be used only as a last resort. Because it is executed |
| very early, most of the Objective-C runtime machinery will not be ready |
| when `+load' is executed; hence `+load' works best for executing C code |
| that is independent on the Objective-C runtime. |
| |
| The `+load' implementation in the GNU runtime guarantees you the |
| following things: |
| |
| * you can write whatever C code you like; |
| |
| * you can allocate and send messages to objects whose class is |
| implemented in the same file; |
| |
| * the `+load' implementation of all super classes of a class are |
| executed before the `+load' of that class is executed; |
| |
| * the `+load' implementation of a class is executed before the |
| `+load' implementation of any category. |
| |
| |
| In particular, the following things, even if they can work in a |
| particular case, are not guaranteed: |
| |
| * allocation of or sending messages to arbitrary objects; |
| |
| * allocation of or sending messages to objects whose classes have a |
| category implemented in the same file; |
| |
| * sending messages to Objective-C constant strings (`@"this is a |
| constant string"'); |
| |
| |
| You should make no assumptions about receiving `+load' in sibling |
| classes when you write `+load' of a class. The order in which sibling |
| classes receive `+load' is not guaranteed. |
| |
| The order in which `+load' and `+initialize' are called could be |
| problematic if this matters. If you don't allocate objects inside |
| `+load', it is guaranteed that `+load' is called before `+initialize'. |
| If you create an object inside `+load' the `+initialize' method of |
| object's class is invoked even if `+load' was not invoked. Note if you |
| explicitly call `+load' on a class, `+initialize' will be called first. |
| To avoid possible problems try to implement only one of these methods. |
| |
| The `+load' method is also invoked when a bundle is dynamically loaded |
| into your running program. This happens automatically without any |
| intervening operation from you. When you write bundles and you need to |
| write `+load' you can safely create and send messages to objects whose |
| classes already exist in the running program. The same restrictions as |
| above apply to classes defined in bundle. |
| |
| |
| File: gcc.info, Node: Type encoding, Next: Garbage Collection, Prev: Executing code before main, Up: Objective-C |
| |
| 8.3 Type encoding |
| ================= |
| |
| This is an advanced section. Type encodings are used extensively by |
| the compiler and by the runtime, but you generally do not need to know |
| about them to use Objective-C. |
| |
| The Objective-C compiler generates type encodings for all the types. |
| These type encodings are used at runtime to find out information about |
| selectors and methods and about objects and classes. |
| |
| The types are encoded in the following way: |
| |
| `_Bool' `B' |
| `char' `c' |
| `unsigned char' `C' |
| `short' `s' |
| `unsigned short' `S' |
| `int' `i' |
| `unsigned int' `I' |
| `long' `l' |
| `unsigned long' `L' |
| `long long' `q' |
| `unsigned long `Q' |
| long' |
| `float' `f' |
| `double' `d' |
| `long double' `D' |
| `void' `v' |
| `id' `@' |
| `Class' `#' |
| `SEL' `:' |
| `char*' `*' |
| `enum' an `enum' is encoded exactly as the integer type that |
| the compiler uses for it, which depends on the |
| enumeration values. Often the compiler users |
| `unsigned int', which is then encoded as `I'. |
| unknown type `?' |
| Complex types `j' followed by the inner type. For example |
| `_Complex double' is encoded as "jd". |
| bit-fields `b' followed by the starting position of the |
| bit-field, the type of the bit-field and the size of |
| the bit-field (the bit-fields encoding was changed |
| from the NeXT's compiler encoding, see below) |
| |
| The encoding of bit-fields has changed to allow bit-fields to be |
| properly handled by the runtime functions that compute sizes and |
| alignments of types that contain bit-fields. The previous encoding |
| contained only the size of the bit-field. Using only this information |
| it is not possible to reliably compute the size occupied by the |
| bit-field. This is very important in the presence of the Boehm's |
| garbage collector because the objects are allocated using the typed |
| memory facility available in this collector. The typed memory |
| allocation requires information about where the pointers are located |
| inside the object. |
| |
| The position in the bit-field is the position, counting in bits, of the |
| bit closest to the beginning of the structure. |
| |
| The non-atomic types are encoded as follows: |
| |
| pointers `^' followed by the pointed type. |
| arrays `[' followed by the number of elements in the array |
| followed by the type of the elements followed by `]' |
| structures `{' followed by the name of the structure (or `?' if the |
| structure is unnamed), the `=' sign, the type of the |
| members and by `}' |
| unions `(' followed by the name of the structure (or `?' if the |
| union is unnamed), the `=' sign, the type of the members |
| followed by `)' |
| vectors `![' followed by the vector_size (the number of bytes |
| composing the vector) followed by a comma, followed by |
| the alignment (in bytes) of the vector, followed by the |
| type of the elements followed by `]' |
| |
| Here are some types and their encodings, as they are generated by the |
| compiler on an i386 machine: |
| |
| |
| Objective-C type Compiler encoding |
| int a[10]; `[10i]' |
| struct { `{?=i[3f]b128i3b131i2c}' |
| int i; |
| float f[3]; |
| int a:3; |
| int b:2; |
| char c; |
| } |
| int a __attribute__ ((vector_size (16)));`![16,16i]' (alignment would depend on the machine) |
| |
| |
| In addition to the types the compiler also encodes the type |
| specifiers. The table below describes the encoding of the current |
| Objective-C type specifiers: |
| |
| |
| Specifier Encoding |
| `const' `r' |
| `in' `n' |
| `inout' `N' |
| `out' `o' |
| `bycopy' `O' |
| `byref' `R' |
| `oneway' `V' |
| |
| |
| The type specifiers are encoded just before the type. Unlike types |
| however, the type specifiers are only encoded when they appear in method |
| argument types. |
| |
| Note how `const' interacts with pointers: |
| |
| |
| Objective-C type Compiler encoding |
| const int `ri' |
| const int* `^ri' |
| int *const `r^i' |
| |
| |
| `const int*' is a pointer to a `const int', and so is encoded as |
| `^ri'. `int* const', instead, is a `const' pointer to an `int', and so |
| is encoded as `r^i'. |
| |
| Finally, there is a complication when encoding `const char *' versus |
| `char * const'. Because `char *' is encoded as `*' and not as `^c', |
| there is no way to express the fact that `r' applies to the pointer or |
| to the pointee. |
| |
| Hence, it is assumed as a convention that `r*' means `const char *' |
| (since it is what is most often meant), and there is no way to encode |
| `char *const'. `char *const' would simply be encoded as `*', and the |
| `const' is lost. |
| |
| * Menu: |
| |
| * Legacy type encoding:: |
| * @encode:: |
| * Method signatures:: |
| |
| |
| File: gcc.info, Node: Legacy type encoding, Next: @encode, Up: Type encoding |
| |
| 8.3.1 Legacy type encoding |
| -------------------------- |
| |
| Unfortunately, historically GCC used to have a number of bugs in its |
| encoding code. The NeXT runtime expects GCC to emit type encodings in |
| this historical format (compatible with GCC-3.3), so when using the |
| NeXT runtime, GCC will introduce on purpose a number of incorrect |
| encodings: |
| |
| * the read-only qualifier of the pointee gets emitted before the '^'. |
| The read-only qualifier of the pointer itself gets ignored, unless |
| it is a typedef. Also, the 'r' is only emitted for the outermost |
| type. |
| |
| * 32-bit longs are encoded as 'l' or 'L', but not always. For |
| typedefs, the compiler uses 'i' or 'I' instead if encoding a |
| struct field or a pointer. |
| |
| * `enum's are always encoded as 'i' (int) even if they are actually |
| unsigned or long. |
| |
| |
| In addition to that, the NeXT runtime uses a different encoding for |
| bitfields. It encodes them as `b' followed by the size, without a bit |
| offset or the underlying field type. |
| |
| |
| File: gcc.info, Node: @encode, Next: Method signatures, Prev: Legacy type encoding, Up: Type encoding |
| |
| 8.3.2 @encode |
| ------------- |
| |
| GNU Objective-C supports the `@encode' syntax that allows you to create |
| a type encoding from a C/Objective-C type. For example, `@encode(int)' |
| is compiled by the compiler into `"i"'. |
| |
| `@encode' does not support type qualifiers other than `const'. For |
| example, `@encode(const char*)' is valid and is compiled into `"r*"', |
| while `@encode(bycopy char *)' is invalid and will cause a compilation |
| error. |
| |
| |
| File: gcc.info, Node: Method signatures, Prev: @encode, Up: Type encoding |
| |
| 8.3.3 Method signatures |
| ----------------------- |
| |
| This section documents the encoding of method types, which is rarely |
| needed to use Objective-C. You should skip it at a first reading; the |
| runtime provides functions that will work on methods and can walk |
| through the list of parameters and interpret them for you. These |
| functions are part of the public "API" and are the preferred way to |
| interact with method signatures from user code. |
| |
| But if you need to debug a problem with method signatures and need to |
| know how they are implemented (i.e., the "ABI"), read on. |
| |
| Methods have their "signature" encoded and made available to the |
| runtime. The "signature" encodes all the information required to |
| dynamically build invocations of the method at runtime: return type and |
| arguments. |
| |
| The "signature" is a null-terminated string, composed of the following: |
| |
| * The return type, including type qualifiers. For example, a method |
| returning `int' would have `i' here. |
| |
| * The total size (in bytes) required to pass all the parameters. |
| This includes the two hidden parameters (the object `self' and the |
| method selector `_cmd'). |
| |
| * Each argument, with the type encoding, followed by the offset (in |
| bytes) of the argument in the list of parameters. |
| |
| |
| For example, a method with no arguments and returning `int' would have |
| the signature `i8@0:4' if the size of a pointer is 4. The signature is |
| interpreted as follows: the `i' is the return type (an `int'), the `8' |
| is the total size of the parameters in bytes (two pointers each of size |
| 4), the `@0' is the first parameter (an object at byte offset `0') and |
| `:4' is the second parameter (a `SEL' at byte offset `4'). |
| |
| You can easily find more examples by running the "strings" program on |
| an Objective-C object file compiled by GCC. You'll see a lot of |
| strings that look very much like `i8@0:4'. They are signatures of |
| Objective-C methods. |
| |
| |
| File: gcc.info, Node: Garbage Collection, Next: Constant string objects, Prev: Type encoding, Up: Objective-C |
| |
| 8.4 Garbage Collection |
| ====================== |
| |
| This section is specific for the GNU Objective-C runtime. If you are |
| using a different runtime, you can skip it. |
| |
| Support for garbage collection with the GNU runtime has been added by |
| using a powerful conservative garbage collector, known as the |
| Boehm-Demers-Weiser conservative garbage collector. |
| |
| To enable the support for it you have to configure the compiler using |
| an additional argument, `--enable-objc-gc'. This will build the |
| boehm-gc library, and build an additional runtime library which has |
| several enhancements to support the garbage collector. The new library |
| has a new name, `libobjc_gc.a' to not conflict with the |
| non-garbage-collected library. |
| |
| When the garbage collector is used, the objects are allocated using the |
| so-called typed memory allocation mechanism available in the |
| Boehm-Demers-Weiser collector. This mode requires precise information |
| on where pointers are located inside objects. This information is |
| computed once per class, immediately after the class has been |
| initialized. |
| |
| There is a new runtime function `class_ivar_set_gcinvisible()' which |
| can be used to declare a so-called "weak pointer" reference. Such a |
| pointer is basically hidden for the garbage collector; this can be |
| useful in certain situations, especially when you want to keep track of |
| the allocated objects, yet allow them to be collected. This kind of |
| pointers can only be members of objects, you cannot declare a global |
| pointer as a weak reference. Every type which is a pointer type can be |
| declared a weak pointer, including `id', `Class' and `SEL'. |
| |
| Here is an example of how to use this feature. Suppose you want to |
| implement a class whose instances hold a weak pointer reference; the |
| following class does this: |
| |
| |
| @interface WeakPointer : Object |
| { |
| const void* weakPointer; |
| } |
| |
| - initWithPointer:(const void*)p; |
| - (const void*)weakPointer; |
| @end |
| |
| |
| @implementation WeakPointer |
| |
| + (void)initialize |
| { |
| class_ivar_set_gcinvisible (self, "weakPointer", YES); |
| } |
| |
| - initWithPointer:(const void*)p |
| { |
| weakPointer = p; |
| return self; |
| } |
| |
| - (const void*)weakPointer |
| { |
| return weakPointer; |
| } |
| |
| @end |
| |
| Weak pointers are supported through a new type character specifier |
| represented by the `!' character. The `class_ivar_set_gcinvisible()' |
| function adds or removes this specifier to the string type description |
| of the instance variable named as argument. |
| |
| |
| File: gcc.info, Node: Constant string objects, Next: compatibility_alias, Prev: Garbage Collection, Up: Objective-C |
| |
| 8.5 Constant string objects |
| =========================== |
| |
| GNU Objective-C provides constant string objects that are generated |
| directly by the compiler. You declare a constant string object by |
| prefixing a C constant string with the character `@': |
| |
| id myString = @"this is a constant string object"; |
| |
| The constant string objects are by default instances of the |
| `NXConstantString' class which is provided by the GNU Objective-C |
| runtime. To get the definition of this class you must include the |
| `objc/NXConstStr.h' header file. |
| |
| User defined libraries may want to implement their own constant string |
| class. To be able to support them, the GNU Objective-C compiler |
| provides a new command line options |
| `-fconstant-string-class=CLASS-NAME'. The provided class should adhere |
| to a strict structure, the same as `NXConstantString''s structure: |
| |
| |
| @interface MyConstantStringClass |
| { |
| Class isa; |
| char *c_string; |
| unsigned int len; |
| } |
| @end |
| |
| `NXConstantString' inherits from `Object'; user class libraries may |
| choose to inherit the customized constant string class from a different |
| class than `Object'. There is no requirement in the methods the |
| constant string class has to implement, but the final ivar layout of |
| the class must be the compatible with the given structure. |
| |
| When the compiler creates the statically allocated constant string |
| object, the `c_string' field will be filled by the compiler with the |
| string; the `length' field will be filled by the compiler with the |
| string length; the `isa' pointer will be filled with `NULL' by the |
| compiler, and it will later be fixed up automatically at runtime by the |
| GNU Objective-C runtime library to point to the class which was set by |
| the `-fconstant-string-class' option when the object file is loaded (if |
| you wonder how it works behind the scenes, the name of the class to |
| use, and the list of static objects to fixup, are stored by the |
| compiler in the object file in a place where the GNU runtime library |
| will find them at runtime). |
| |
| As a result, when a file is compiled with the |
| `-fconstant-string-class' option, all the constant string objects will |
| be instances of the class specified as argument to this option. It is |
| possible to have multiple compilation units referring to different |
| constant string classes, neither the compiler nor the linker impose any |
| restrictions in doing this. |
| |
| |
| File: gcc.info, Node: compatibility_alias, Next: Exceptions, Prev: Constant string objects, Up: Objective-C |
| |
| 8.6 compatibility_alias |
| ======================= |
| |
| The keyword `@compatibility_alias' allows you to define a class name as |
| equivalent to another class name. For example: |
| |
| @compatibility_alias WOApplication GSWApplication; |
| |
| tells the compiler that each time it encounters `WOApplication' as a |
| class name, it should replace it with `GSWApplication' (that is, |
| `WOApplication' is just an alias for `GSWApplication'). |
| |
| There are some constraints on how this can be used-- |
| |
| * `WOApplication' (the alias) must not be an existing class; |
| |
| * `GSWApplication' (the real class) must be an existing class. |
| |
| |
| |
| File: gcc.info, Node: Exceptions, Next: Synchronization, Prev: compatibility_alias, Up: Objective-C |
| |
| 8.7 Exceptions |
| ============== |
| |
| GNU Objective-C provides exception support built into the language, as |
| in the following example: |
| |
| @try { |
| ... |
| @throw expr; |
| ... |
| } |
| @catch (AnObjCClass *exc) { |
| ... |
| @throw expr; |
| ... |
| @throw; |
| ... |
| } |
| @catch (AnotherClass *exc) { |
| ... |
| } |
| @catch (id allOthers) { |
| ... |
| } |
| @finally { |
| ... |
| @throw expr; |
| ... |
| } |
| |
| The `@throw' statement may appear anywhere in an Objective-C or |
| Objective-C++ program; when used inside of a `@catch' block, the |
| `@throw' may appear without an argument (as shown above), in which case |
| the object caught by the `@catch' will be rethrown. |
| |
| Note that only (pointers to) Objective-C objects may be thrown and |
| caught using this scheme. When an object is thrown, it will be caught |
| by the nearest `@catch' clause capable of handling objects of that |
| type, analogously to how `catch' blocks work in C++ and Java. A |
| `@catch(id ...)' clause (as shown above) may also be provided to catch |
| any and all Objective-C exceptions not caught by previous `@catch' |
| clauses (if any). |
| |
| The `@finally' clause, if present, will be executed upon exit from the |
| immediately preceding `@try ... @catch' section. This will happen |
| regardless of whether any exceptions are thrown, caught or rethrown |
| inside the `@try ... @catch' section, analogously to the behavior of |
| the `finally' clause in Java. |
| |
| There are several caveats to using the new exception mechanism: |
| |
| * The `-fobjc-exceptions' command line option must be used when |
| compiling Objective-C files that use exceptions. |
| |
| * With the GNU runtime, exceptions are always implemented as "native" |
| exceptions and it is recommended that the `-fexceptions' and |
| `-shared-libgcc' options are used when linking. |
| |
| * With the NeXT runtime, although currently designed to be binary |
| compatible with `NS_HANDLER'-style idioms provided by the |
| `NSException' class, the new exceptions can only be used on Mac OS |
| X 10.3 (Panther) and later systems, due to additional functionality |
| needed in the NeXT Objective-C runtime. |
| |
| * As mentioned above, the new exceptions do not support handling |
| types other than Objective-C objects. Furthermore, when used from |
| Objective-C++, the Objective-C exception model does not |
| interoperate with C++ exceptions at this time. This means you |
| cannot `@throw' an exception from Objective-C and `catch' it in |
| C++, or vice versa (i.e., `throw ... @catch'). |
| |
| |
| File: gcc.info, Node: Synchronization, Next: Fast enumeration, Prev: Exceptions, Up: Objective-C |
| |
| 8.8 Synchronization |
| =================== |
| |
| GNU Objective-C provides support for synchronized blocks: |
| |
| @synchronized (ObjCClass *guard) { |
| ... |
| } |
| |
| Upon entering the `@synchronized' block, a thread of execution shall |
| first check whether a lock has been placed on the corresponding `guard' |
| object by another thread. If it has, the current thread shall wait |
| until the other thread relinquishes its lock. Once `guard' becomes |
| available, the current thread will place its own lock on it, execute |
| the code contained in the `@synchronized' block, and finally relinquish |
| the lock (thereby making `guard' available to other threads). |
| |
| Unlike Java, Objective-C does not allow for entire methods to be |
| marked `@synchronized'. Note that throwing exceptions out of |
| `@synchronized' blocks is allowed, and will cause the guarding object |
| to be unlocked properly. |
| |
| Because of the interactions between synchronization and exception |
| handling, you can only use `@synchronized' when compiling with |
| exceptions enabled, that is with the command line option |
| `-fobjc-exceptions'. |
| |
| |
| File: gcc.info, Node: Fast enumeration, Next: Messaging with the GNU Objective-C runtime, Prev: Synchronization, Up: Objective-C |
| |
| 8.9 Fast enumeration |
| ==================== |
| |
| * Menu: |
| |
| * Using fast enumeration:: |
| * c99-like fast enumeration syntax:: |
| * Fast enumeration details:: |
| * Fast enumeration protocol:: |
| |
| |
| File: gcc.info, Node: Using fast enumeration, Next: c99-like fast enumeration syntax, Up: Fast enumeration |
| |
| 8.9.1 Using fast enumeration |
| ---------------------------- |
| |
| GNU Objective-C provides support for the fast enumeration syntax: |
| |
| id array = ...; |
| id object; |
| |
| for (object in array) |
| { |
| /* Do something with 'object' */ |
| } |
| |
| `array' needs to be an Objective-C object (usually a collection |
| object, for example an array, a dictionary or a set) which implements |
| the "Fast Enumeration Protocol" (see below). If you are using a |
| Foundation library such as GNUstep Base or Apple Cocoa Foundation, all |
| collection objects in the library implement this protocol and can be |
| used in this way. |
| |
| The code above would iterate over all objects in `array'. For each of |
| them, it assigns it to `object', then executes the `Do something with |
| 'object'' statements. |
| |
| Here is a fully worked-out example using a Foundation library (which |
| provides the implementation of `NSArray', `NSString' and `NSLog'): |
| |
| NSArray *array = [NSArray arrayWithObjects: @"1", @"2", @"3", nil]; |
| NSString *object; |
| |
| for (object in array) |
| NSLog (@"Iterating over %@", object); |
| |
| |
| File: gcc.info, Node: c99-like fast enumeration syntax, Next: Fast enumeration details, Prev: Using fast enumeration, Up: Fast enumeration |
| |
| 8.9.2 c99-like fast enumeration syntax |
| -------------------------------------- |
| |
| A c99-like declaration syntax is also allowed: |
| |
| id array = ...; |
| |
| for (id object in array) |
| { |
| /* Do something with 'object' */ |
| } |
| |
| this is completely equivalent to: |
| |
| id array = ...; |
| |
| { |
| id object; |
| for (object in array) |
| { |
| /* Do something with 'object' */ |
| } |
| } |
| |
| but can save some typing. |
| |
| Note that the option `-std=c99' is not required to allow this syntax |
| in Objective-C. |
| |
| |
| File: gcc.info, Node: Fast enumeration details, Next: Fast enumeration protocol, Prev: c99-like fast enumeration syntax, Up: Fast enumeration |
| |
| 8.9.3 Fast enumeration details |
| ------------------------------ |
| |
| Here is a more technical description with the gory details. Consider |
| the code |
| |
| for (OBJECT EXPRESSION in COLLECTION EXPRESSION) |
| { |
| STATEMENTS |
| } |
| |
| here is what happens when you run it: |
| |
| * `COLLECTION EXPRESSION' is evaluated exactly once and the result |
| is used as the collection object to iterate over. This means it |
| is safe to write code such as `for (object in [NSDictionary |
| keyEnumerator]) ...'. |
| |
| * the iteration is implemented by the compiler by repeatedly getting |
| batches of objects from the collection object using the fast |
| enumeration protocol (see below), then iterating over all objects |
| in the batch. This is faster than a normal enumeration where |
| objects are retrieved one by one (hence the name "fast |
| enumeration"). |
| |
| * if there are no objects in the collection, then `OBJECT |
| EXPRESSION' is set to `nil' and the loop immediately terminates. |
| |
| * if there are objects in the collection, then for each object in the |
| collection (in the order they are returned) `OBJECT EXPRESSION' is |
| set to the object, then `STATEMENTS' are executed. |
| |
| * `STATEMENTS' can contain `break' and `continue' commands, which |
| will abort the iteration or skip to the next loop iteration as |
| expected. |
| |
| * when the iteration ends because there are no more objects to |
| iterate over, `OBJECT EXPRESSION' is set to `nil'. This allows |
| you to determine whether the iteration finished because a `break' |
| command was used (in which case `OBJECT EXPRESSION' will remain |
| set to the last object that was iterated over) or because it |
| iterated over all the objects (in which case `OBJECT EXPRESSION' |
| will be set to `nil'). |
| |
| * `STATEMENTS' must not make any changes to the collection object; |
| if they do, it is a hard error and the fast enumeration terminates |
| by invoking `objc_enumerationMutation', a runtime function that |
| normally aborts the program but which can be customized by |
| Foundation libraries via `objc_set_mutation_handler' to do |
| something different, such as raising an exception. |
| |
| |
| |
| File: gcc.info, Node: Fast enumeration protocol, Prev: Fast enumeration details, Up: Fast enumeration |
| |
| 8.9.4 Fast enumeration protocol |
| ------------------------------- |
| |
| If you want your own collection object to be usable with fast |
| enumeration, you need to have it implement the method |
| |
| - (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state |
| objects: (id *)objects |
| count: (unsigned long)len; |
| |
| where `NSFastEnumerationState' must be defined in your code as follows: |
| |
| typedef struct |
| { |
| unsigned long state; |
| id *itemsPtr; |
| unsigned long *mutationsPtr; |
| unsigned long extra[5]; |
| } NSFastEnumerationState; |
| |
| If no `NSFastEnumerationState' is defined in your code, the compiler |
| will automatically replace `NSFastEnumerationState *' with `struct |
| __objcFastEnumerationState *', where that type is silently defined by |
| the compiler in an identical way. This can be confusing and we |
| recommend that you define `NSFastEnumerationState' (as shown above) |
| instead. |
| |
| The method is called repeatedly during a fast enumeration to retrieve |
| batches of objects. Each invocation of the method should retrieve the |
| next batch of objects. |
| |
| The return value of the method is the number of objects in the current |
| batch; this should not exceed `len', which is the maximum size of a |
| batch as requested by the caller. The batch itself is returned in the |
| `itemsPtr' field of the `NSFastEnumerationState' struct. |
| |
| To help with returning the objects, the `objects' array is a C array |
| preallocated by the caller (on the stack) of size `len'. In many cases |
| you can put the objects you want to return in that `objects' array, |
| then do `itemsPtr = objects'. But you don't have to; if your |
| collection already has the objects to return in some form of C array, |
| it could return them from there instead. |
| |
| The `state' and `extra' fields of the `NSFastEnumerationState' |
| structure allows your collection object to keep track of the state of |
| the enumeration. In a simple array implementation, `state' may keep |
| track of the index of the last object that was returned, and `extra' |
| may be unused. |
| |
| The `mutationsPtr' field of the `NSFastEnumerationState' is used to |
| keep track of mutations. It should point to a number; before working |
| on each object, the fast enumeration loop will check that this number |
| has not changed. If it has, a mutation has happened and the fast |
| enumeration will abort. So, `mutationsPtr' could be set to point to |
| some sort of version number of your collection, which is increased by |
| one every time there is a change (for example when an object is added |
| or removed). Or, if you are content with less strict mutation checks, |
| it could point to the number of objects in your collection or some |
| other value that can be checked to perform an approximate check that |
| the collection has not been mutated. |
| |
| Finally, note how we declared the `len' argument and the return value |
| to be of type `unsigned long'. They could also be declared to be of |
| type `unsigned int' and everything would still work. |
| |
| |
| File: gcc.info, Node: Messaging with the GNU Objective-C runtime, Prev: Fast enumeration, Up: Objective-C |
| |
| 8.10 Messaging with the GNU Objective-C runtime |
| =============================================== |
| |
| This section is specific for the GNU Objective-C runtime. If you are |
| using a different runtime, you can skip it. |
| |
| The implementation of messaging in the GNU Objective-C runtime is |
| designed to be portable, and so is based on standard C. |
| |
| Sending a message in the GNU Objective-C runtime is composed of two |
| separate steps. First, there is a call to the lookup function, |
| `objc_msg_lookup ()' (or, in the case of messages to super, |
| `objc_msg_lookup_super ()'). This runtime function takes as argument |
| the receiver and the selector of the method to be called; it returns |
| the `IMP', that is a pointer to the function implementing the method. |
| The second step of method invocation consists of casting this pointer |
| function to the appropriate function pointer type, and calling the |
| function pointed to it with the right arguments. |
| |
| For example, when the compiler encounters a method invocation such as |
| `[object init]', it compiles it into a call to `objc_msg_lookup |
| (object, @selector(init))' followed by a cast of the returned value to |
| the appropriate function pointer type, and then it calls it. |
| |
| * Menu: |
| |
| * Dynamically registering methods:: |
| * Forwarding hook:: |
| |
| |
| File: gcc.info, Node: Dynamically registering methods, Next: Forwarding hook, Up: Messaging with the GNU Objective-C runtime |
| |
| 8.10.1 Dynamically registering methods |
| -------------------------------------- |
| |
| If `objc_msg_lookup()' does not find a suitable method implementation, |
| because the receiver does not implement the required method, it tries |
| to see if the class can dynamically register the method. |
| |
| To do so, the runtime checks if the class of the receiver implements |
| the method |
| |
| + (BOOL) resolveInstanceMethod: (SEL)selector; |
| |
| in the case of an instance method, or |
| |
| + (BOOL) resolveClassMethod: (SEL)selector; |
| |
| in the case of a class method. If the class implements it, the |
| runtime invokes it, passing as argument the selector of the original |
| method, and if it returns `YES', the runtime tries the lookup again, |
| which could now succeed if a matching method was added dynamically by |
| `+resolveInstanceMethod:' or `+resolveClassMethod:'. |
| |
| This allows classes to dynamically register methods (by adding them to |
| the class using `class_addMethod') when they are first called. To do |
| so, a class should implement `+resolveInstanceMethod:' (or, depending |
| on the case, `+resolveClassMethod:') and have it recognize the |
| selectors of methods that can be registered dynamically at runtime, |
| register them, and return `YES'. It should return `NO' for methods |
| that it does not dynamically registered at runtime. |
| |
| If `+resolveInstanceMethod:' (or `+resolveClassMethod:') is not |
| implemented or returns `NO', the runtime then tries the forwarding hook. |
| |
| Support for `+resolveInstanceMethod:' and `resolveClassMethod:' was |
| added to the GNU Objective-C runtime in GCC version 4.6. |
| |
| |
| File: gcc.info, Node: Forwarding hook, Prev: Dynamically registering methods, Up: Messaging with the GNU Objective-C runtime |
| |
| 8.10.2 Forwarding hook |
| ---------------------- |
| |
| The GNU Objective-C runtime provides a hook, called |
| `__objc_msg_forward2', which is called by `objc_msg_lookup()' when it |
| can't find a method implementation in the runtime tables and after |
| calling `+resolveInstanceMethod:' and `+resolveClassMethod:' has been |
| attempted and did not succeed in dynamically registering the method. |
| |
| To configure the hook, you set the global variable |
| `__objc_msg_foward2' to a function with the same argument and return |
| types of `objc_msg_lookup()'. When `objc_msg_lookup()' can not find a |
| method implementation, it invokes the hook function you provided to get |
| a method implementation to return. So, in practice |
| `__objc_msg_forward2' allows you to extend `objc_msg_lookup()' by |
| adding some custom code that is called to do a further lookup when no |
| standard method implementation can be found using the normal lookup. |
| |
| This hook is generally reserved for "Foundation" libraries such as |
| GNUstep Base, which use it to implement their high-level method |
| forwarding API, typically based around the `forwardInvocation:' method. |
| So, unless you are implementing your own "Foundation" library, you |
| should not set this hook. |
| |
| In a typical forwarding implementation, the `__objc_msg_forward2' hook |
| function determines the argument and return type of the method that is |
| being looked up, and then creates a function that takes these arguments |
| and has that return type, and returns it to the caller. Creating this |
| function is non-trivial and is typically performed using a dedicated |
| library such as `libffi'. |
| |
| The forwarding method implementation thus created is returned by |
| `objc_msg_lookup()' and is executed as if it was a normal method |
| implementation. When the forwarding method implementation is called, |
| it is usually expected to pack all arguments into some sort of object |
| (typically, an `NSInvocation' in a "Foundation" library), and hand it |
| over to the programmer (`forwardInvocation:') who is then allowed to |
| manipulate the method invocation using a high-level API provided by the |
| "Foundation" library. For example, the programmer may want to examine |
| the method invocation arguments and name and potentially change them |
| before forwarding the method invocation to one or more local objects |
| (`performInvocation:') or even to remote objects (by using Distributed |
| Objects or some other mechanism). When all this completes, the return |
| value is passed back and must be returned correctly to the original |
| caller. |
| |
| Note that the GNU Objective-C runtime currently provides no support |
| for method forwarding or method invocations other than the |
| `__objc_msg_forward2' hook. |
| |
| If the forwarding hook does not exist or returns `NULL', the runtime |
| currently attempts forwarding using an older, deprecated API, and if |
| that fails, it aborts the program. In future versions of the GNU |
| Objective-C runtime, the runtime will immediately abort. |
| |
| |
| File: gcc.info, Node: Compatibility, Next: Gcov, Prev: Objective-C, Up: Top |
| |
| 9 Binary Compatibility |
| ********************** |
| |
| Binary compatibility encompasses several related concepts: |
| |
| "application binary interface (ABI)" |
| The set of runtime conventions followed by all of the tools that |
| deal with binary representations of a program, including |
| compilers, assemblers, linkers, and language runtime support. |
| Some ABIs are formal with a written specification, possibly |
| designed by multiple interested parties. Others are simply the |
| way things are actually done by a particular set of tools. |
| |
| "ABI conformance" |
| A compiler conforms to an ABI if it generates code that follows |
| all of the specifications enumerated by that ABI. A library |
| conforms to an ABI if it is implemented according to that ABI. An |
| application conforms to an ABI if it is built using tools that |
| conform to that ABI and does not contain source code that |
| specifically changes behavior specified by the ABI. |
| |
| "calling conventions" |
| Calling conventions are a subset of an ABI that specify of how |
| arguments are passed and function results are returned. |
| |
| "interoperability" |
| Different sets of tools are interoperable if they generate files |
| that can be used in the same program. The set of tools includes |
| compilers, assemblers, linkers, libraries, header files, startup |
| files, and debuggers. Binaries produced by different sets of |
| tools are not interoperable unless they implement the same ABI. |
| This applies to different versions of the same tools as well as |
| tools from different vendors. |
| |
| "intercallability" |
| Whether a function in a binary built by one set of tools can call a |
| function in a binary built by a different set of tools is a subset |
| of interoperability. |
| |
| "implementation-defined features" |
| Language standards include lists of implementation-defined |
| features whose behavior can vary from one implementation to |
| another. Some of these features are normally covered by a |
| platform's ABI and others are not. The features that are not |
| covered by an ABI generally affect how a program behaves, but not |
| intercallability. |
| |
| "compatibility" |
| Conformance to the same ABI and the same behavior of |
| implementation-defined features are both relevant for |
| compatibility. |
| |
| The application binary interface implemented by a C or C++ compiler |
| affects code generation and runtime support for: |
| |
| * size and alignment of data types |
| |
| * layout of structured types |
| |
| * calling conventions |
| |
| * register usage conventions |
| |
| * interfaces for runtime arithmetic support |
| |
| * object file formats |
| |
| In addition, the application binary interface implemented by a C++ |
| compiler affects code generation and runtime support for: |
| * name mangling |
| |
| * exception handling |
| |
| * invoking constructors and destructors |
| |
| * layout, alignment, and padding of classes |
| |
| * layout and alignment of virtual tables |
| |
| Some GCC compilation options cause the compiler to generate code that |
| does not conform to the platform's default ABI. Other options cause |
| different program behavior for implementation-defined features that are |
| not covered by an ABI. These options are provided for consistency with |
| other compilers that do not follow the platform's default ABI or the |
| usual behavior of implementation-defined features for the platform. Be |
| very careful about using such options. |
| |
| Most platforms have a well-defined ABI that covers C code, but ABIs |
| that cover C++ functionality are not yet common. |
| |
| Starting with GCC 3.2, GCC binary conventions for C++ are based on a |
| written, vendor-neutral C++ ABI that was designed to be specific to |
| 64-bit Itanium but also includes generic specifications that apply to |
| any platform. This C++ ABI is also implemented by other compiler |
| vendors on some platforms, notably GNU/Linux and BSD systems. We have |
| tried hard to provide a stable ABI that will be compatible with future |
| GCC releases, but it is possible that we will encounter problems that |
| make this difficult. Such problems could include different |
| interpretations of the C++ ABI by different vendors, bugs in the ABI, or |
| bugs in the implementation of the ABI in different compilers. GCC's |
| `-Wabi' switch warns when G++ generates code that is probably not |
| compatible with the C++ ABI. |
| |
| The C++ library used with a C++ compiler includes the Standard C++ |
| Library, with functionality defined in the C++ Standard, plus language |
| runtime support. The runtime support is included in a C++ ABI, but |
| there is no formal ABI for the Standard C++ Library. Two |
| implementations of that library are interoperable if one follows the |
| de-facto ABI of the other and if they are both built with the same |
| compiler, or with compilers that conform to the same ABI for C++ |
| compiler and runtime support. |
| |
| When G++ and another C++ compiler conform to the same C++ ABI, but the |
| implementations of the Standard C++ Library that they normally use do |
| not follow the same ABI for the Standard C++ Library, object files |
| built with those compilers can be used in the same program only if they |
| use the same C++ library. This requires specifying the location of the |
| C++ library header files when invoking the compiler whose usual library |
| is not being used. The location of GCC's C++ header files depends on |
| how the GCC build was configured, but can be seen by using the G++ `-v' |
| option. With default configuration options for G++ 3.3 the compile |
| line for a different C++ compiler needs to include |
| |
| -IGCC_INSTALL_DIRECTORY/include/c++/3.3 |
| |
| Similarly, compiling code with G++ that must use a C++ library other |
| than the GNU C++ library requires specifying the location of the header |
| files for that other library. |
| |
| The most straightforward way to link a program to use a particular C++ |
| library is to use a C++ driver that specifies that C++ library by |
| default. The `g++' driver, for example, tells the linker where to find |
| GCC's C++ library (`libstdc++') plus the other libraries and startup |
| files it needs, in the proper order. |
| |
| If a program must use a different C++ library and it's not possible to |
| do the final link using a C++ driver that uses that library by default, |
| it is necessary to tell `g++' the location and name of that library. |
| It might also be necessary to specify different startup files and other |
| runtime support libraries, and to suppress the use of GCC's support |
| libraries with one or more of the options `-nostdlib', `-nostartfiles', |
| and `-nodefaultlibs'. |
| |
| |
| File: gcc.info, Node: Gcov, Next: Trouble, Prev: Compatibility, Up: Top |
| |
| 10 `gcov'--a Test Coverage Program |
| ********************************** |
| |
| `gcov' is a tool you can use in conjunction with GCC to test code |
| coverage in your programs. |
| |
| * Menu: |
| |
| * Gcov Intro:: Introduction to gcov. |
| * Invoking Gcov:: How to use gcov. |
| * Gcov and Optimization:: Using gcov with GCC optimization. |
| * Gcov Data Files:: The files used by gcov. |
| * Cross-profiling:: Data file relocation. |
| |
| |
| File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov |
| |
| 10.1 Introduction to `gcov' |
| =========================== |
| |
| `gcov' is a test coverage program. Use it in concert with GCC to |
| analyze your programs to help create more efficient, faster running |
| code and to discover untested parts of your program. You can use |
| `gcov' as a profiling tool to help discover where your optimization |
| efforts will best affect your code. You can also use `gcov' along with |
| the other profiling tool, `gprof', to assess which parts of your code |
| use the greatest amount of computing time. |
| |
| Profiling tools help you analyze your code's performance. Using a |
| profiler such as `gcov' or `gprof', you can find out some basic |
| performance statistics, such as: |
| |
| * how often each line of code executes |
| |
| * what lines of code are actually executed |
| |
| * how much computing time each section of code uses |
| |
| Once you know these things about how your code works when compiled, you |
| can look at each module to see which modules should be optimized. |
| `gcov' helps you determine where to work on optimization. |
| |
| Software developers also use coverage testing in concert with |
| testsuites, to make sure software is actually good enough for a release. |
| Testsuites can verify that a program works as expected; a coverage |
| program tests to see how much of the program is exercised by the |
| testsuite. Developers can then determine what kinds of test cases need |
| to be added to the testsuites to create both better testing and a better |
| final product. |
| |
| You should compile your code without optimization if you plan to use |
| `gcov' because the optimization, by combining some lines of code into |
| one function, may not give you as much information as you need to look |
| for `hot spots' where the code is using a great deal of computer time. |
| Likewise, because `gcov' accumulates statistics by line (at the lowest |
| resolution), it works best with a programming style that places only |
| one statement on each line. If you use complicated macros that expand |
| to loops or to other control structures, the statistics are less |
| helpful--they only report on the line where the macro call appears. If |
| your complex macros behave like functions, you can replace them with |
| inline functions to solve this problem. |
| |
| `gcov' creates a logfile called `SOURCEFILE.gcov' which indicates how |
| many times each line of a source file `SOURCEFILE.c' has executed. You |
| can use these logfiles along with `gprof' to aid in fine-tuning the |
| performance of your programs. `gprof' gives timing information you can |
| use along with the information you get from `gcov'. |
| |
| `gcov' works only on code compiled with GCC. It is not compatible |
| with any other profiling or test coverage mechanism. |
| |
| |
| File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov |
| |
| 10.2 Invoking `gcov' |
| ==================== |
| |
| gcov [OPTIONS] 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. |
| |
| `-m' |
| `--pmu-profile' |
| Output the additional PMU profile information if available. |
| |
| `-q' |
| `--pmu_profile-path' |
| PMU profile path (default `pmuprofile.gcda'). |
| |
| `-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. |
| |
| `-d' |
| `--display-progress' |
| Display the progress on the standard output. |
| |
| `-i' |
| `--intermediate-format' |
| Output gcov file in an intermediate text format that can be used by |
| `lcov' or other applications. It will output a single *.gcov file |
| per *.gcda file. No source code is required. |
| |
| The format of the intermediate `.gcov' file is plain text with one |
| entry per line |
| |
| SF:SOURCE_FILE_NAME |
| FN:LINE_NUMBER,FUNCTION_NAME |
| FNDA:EXECUTION_COUNT,FUNCTION_NAME |
| BA:LINE_NUM,BRANCH_COVERAGE_TYPE |
| DA:LINE NUMBER,EXECUTION_COUNT |
| |
| Where the BRANCH_COVERAGE_TYPE is |
| 0 (Branch not executed) |
| 1 (Branch executed, but not taken) |
| 2 (Branch executed and taken) |
| |
| There can be multiple SF entries in an intermediate gcov file. All |
| entries following SF pertain to that source file until the next SF |
| entry. |
| |
| |
| `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. |
| |
| |
| File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov |
| |
| 10.3 Using `gcov' with GCC Optimization |
| ======================================= |
| |
| If you plan to use `gcov' to help optimize your code, you must first |
| compile your program with two special GCC options: `-fprofile-arcs |
| -ftest-coverage'. Aside from that, you can use any other GCC options; |
| but if you want to prove that every single line in your program was |
| executed, you should not compile with optimization at the same time. |
| On some machines the optimizer can eliminate some simple code lines by |
| combining them with other lines. For example, code like this: |
| |
| if (a != b) |
| c = 1; |
| else |
| c = 0; |
| |
| can be compiled into one instruction on some machines. In this case, |
| there is no way for `gcov' to calculate separate execution counts for |
| each line because there isn't separate code for each line. Hence the |
| `gcov' output looks like this if you compiled the program with |
| optimization: |
| |
| 100: 12:if (a != b) |
| 100: 13: c = 1; |
| 100: 14:else |
| 100: 15: c = 0; |
| |
| The output shows that this block of code, combined by optimization, |
| executed 100 times. In one sense this result is correct, because there |
| was only one instruction representing all four of these lines. However, |
| the output does not indicate how many times the result was 0 and how |
| many times the result was 1. |
| |
| Inlineable functions can create unexpected line counts. Line counts |
| are shown for the source code of the inlineable function, but what is |
| shown depends on where the function is inlined, or if it is not inlined |
| at all. |
| |
| If the function is not inlined, the compiler must emit an out of line |
| copy of the function, in any object file that needs it. If `fileA.o' |
| and `fileB.o' both contain out of line bodies of a particular |
| inlineable function, they will also both contain coverage counts for |
| that function. When `fileA.o' and `fileB.o' are linked together, the |
| linker will, on many systems, select one of those out of line bodies |
| for all calls to that function, and remove or ignore the other. |
| Unfortunately, it will not remove the coverage counters for the unused |
| function body. Hence when instrumented, all but one use of that |
| function will show zero counts. |
| |
| If the function is inlined in several places, the block structure in |
| each location might not be the same. For instance, a condition might |
| now be calculable at compile time in some instances. Because the |
| coverage of all the uses of the inline function will be shown for the |
| same source lines, the line counts themselves might seem inconsistent. |
| |
| |
| File: gcc.info, Node: Gcov Data Files, Next: Cross-profiling, Prev: Gcov and Optimization, Up: Gcov |
| |
| 10.4 Brief description of `gcov' data files |
| =========================================== |
| |
| `gcov' uses two files for profiling. The names of these files are |
| derived from the original _object_ file by substituting the file suffix |
| with either `.gcno', or `.gcda'. 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. |
| |
| |
| File: gcc.info, Node: Cross-profiling, Prev: Gcov Data Files, Up: Gcov |
| |
| 10.5 Data file relocation to support cross-profiling |
| ==================================================== |
| |
| Running the program will cause profile output to be generated. For each |
| source file compiled with `-fprofile-arcs', an accompanying `.gcda' |
| file will be placed in the object file directory. That implicitly |
| requires running the program on the same system as it was built or |
| having the same absolute directory structure on the target system. The |
| program will try to create the needed directory structure, if it is not |
| already present. |
| |
| To support cross-profiling, a program compiled with `-fprofile-arcs' |
| can relocate the data files based on two environment variables: |
| |
| * GCOV_PREFIX contains the prefix to add to the absolute paths in |
| the object file. Prefix can be absolute, or relative. The default |
| is no prefix. |
| |
| * GCOV_PREFIX_STRIP indicates the how many initial directory names |
| to strip off the hardwired absolute paths. Default value is 0. |
| |
| _Note:_ If GCOV_PREFIX_STRIP is set without GCOV_PREFIX is |
| undefined, then a relative path is made out of the hardwired |
| absolute paths. |
| |
| For example, if the object file `/user/build/foo.o' was built with |
| `-fprofile-arcs', the final executable will try to create the data file |
| `/user/build/foo.gcda' when running on the target system. This will |
| fail if the corresponding directory does not exist and it is unable to |
| create it. This can be overcome by, for example, setting the |
| environment as `GCOV_PREFIX=/target/run' and `GCOV_PREFIX_STRIP=1'. |
| Such a setting will name the data file `/target/run/build/foo.gcda'. |
| |
| You must move the data files to the expected directory tree in order to |
| use them for profile directed optimizations (`--use-profile'), or to |
| use the `gcov' tool. |
| |
| |
| File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top |
| |
| 11 Known Causes of Trouble with GCC |
| *********************************** |
| |
| This section describes known problems that affect users of GCC. Most |
| of these are not GCC bugs per se--if they were, we would fix them. But |
| the result for a user may be like the result of a bug. |
| |
| Some of these problems are due to bugs in other software, some are |
| missing features that are too much work to add, and some are places |
| where people's opinions differ as to what is best. |
| |
| * Menu: |
| |
| * Actual Bugs:: Bugs we will fix later. |
| * 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++. |
| * Non-bugs:: Things we think are right, but some others disagree. |
| * Warnings and Errors:: Which problems in your code get warnings, |
| and which get errors. |
| |
| |
| File: gcc.info, Node: Actual Bugs, Next: Cross-Compiler Problems, Up: Trouble |
| |
| 11.1 Actual Bugs We Haven't Fixed Yet |
| ===================================== |
| |
| * The `fixincludes' script interacts badly with automounters; if the |
| directory of system header files is automounted, it tends to be |
| unmounted while `fixincludes' is running. This would seem to be a |
| bug in the automounter. We don't know any good way to work around |
| it. |
| |
| |
| File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Actual Bugs, Up: Trouble |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Interoperation, Next: Incompatibilities, Prev: Cross-Compiler Problems, Up: Trouble |
| |
| 11.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. |
| |
| |
| |
| File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: Interoperation, Up: Trouble |
| |
| 11.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, an `extern' declaration affects all the |
| rest of the file even if it happens within a block. |
| |
| * In traditional C, you can combine `long', etc., with a typedef |
| name, as shown here: |
| |
| typedef int foo; |
| typedef long foo bar; |
| |
| In ISO C, this is not allowed: `long' and other type modifiers |
| require an explicit `int'. |
| |
| * PCC allows typedef names to be used as function parameters. |
| |
| * Traditional C allows the following erroneous pair of declarations |
| to appear together in a given scope: |
| |
| typedef int foo; |
| typedef foo foo; |
| |
| * GCC treats all characters of identifiers as significant. |
| According to K&R-1 (2.2), "No more than the first eight characters |
| are significant, although more may be used.". Also according to |
| K&R-1 (2.2), "An identifier is a sequence of letters and digits; |
| the first character must be a letter. The underscore _ counts as |
| a letter.", but GCC also allows dollar signs in identifiers. |
| |
| * PCC allows whitespace in the middle of compound assignment |
| operators such as `+='. GCC, following the ISO standard, does not |
| allow this. |
| |
| * GCC complains about unterminated character constants inside of |
| preprocessing conditionals that fail. Some programs have English |
| comments enclosed in conditionals that are guaranteed to fail; if |
| these comments contain apostrophes, GCC will probably report an |
| error. For example, this code would produce an error: |
| |
| #if 0 |
| You can't expect this to work. |
| #endif |
| |
| The best solution to such a problem is to put the text into an |
| actual C comment delimited by `/*...*/'. |
| |
| * Many user programs contain the declaration `long time ();'. In the |
| past, the system header files on many systems did not actually |
| declare `time', so it did not matter what type your program |
| declared it to return. But in systems with ISO C headers, `time' |
| is declared to return `time_t', and if that is not the same as |
| `long', then `long time ();' is erroneous. |
| |
| The solution is to change your program to use appropriate system |
| headers (`<time.h>' on systems with ISO C headers) and not to |
| declare `time' if the system header files declare it, or failing |
| that to use `time_t' as the return type of `time'. |
| |
| * When compiling functions that return `float', PCC converts it to a |
| double. GCC actually returns a `float'. If you are concerned |
| with PCC compatibility, you should declare your functions to return |
| `double'; you might as well say what you mean. |
| |
| * When compiling functions that return structures or unions, GCC |
| output code normally uses a method different from that used on most |
| versions of Unix. As a result, code compiled with GCC cannot call |
| a structure-returning function compiled with PCC, and vice versa. |
| |
| The method used by GCC is as follows: a structure or union which is |
| 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or |
| union with any other size is stored into an address supplied by |
| the caller (usually in a special, fixed register, but on some |
| machines it is passed on the stack). The target hook |
| `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. |
| |
| By contrast, PCC on most target machines returns structures and |
| unions of any size by copying the data into an area of static |
| storage, and then returning the address of that storage as if it |
| were a pointer value. The caller must copy the data from that |
| memory area to the place where the value is wanted. GCC does not |
| use this method because it is slower and nonreentrant. |
| |
| On some newer machines, PCC uses a reentrant convention for all |
| structure and union returning. GCC on most of these machines uses |
| a compatible convention when returning structures and unions in |
| memory, but still returns small structures and unions in registers. |
| |
| You can tell GCC to use a compatible convention for all structure |
| and union returning with the option `-fpcc-struct-return'. |
| |
| * GCC complains about program fragments such as `0x74ae-0x4000' |
| which appear to be two hexadecimal constants separated by the minus |
| operator. Actually, this string is a single "preprocessing token". |
| Each such token must correspond to one token in C. Since this |
| does not, GCC prints an error message. Although it may appear |
| obvious that what is meant is an operator and two values, the ISO |
| C standard specifically requires that this be treated as erroneous. |
| |
| A "preprocessing token" is a "preprocessing number" if it begins |
| with a digit and is followed by letters, underscores, digits, |
| periods and `e+', `e-', `E+', `E-', `p+', `p-', `P+', or `P-' |
| character sequences. (In strict C90 mode, the sequences `p+', |
| `p-', `P+' and `P-' cannot appear in preprocessing numbers.) |
| |
| To make the above program fragment valid, place whitespace in |
| front of the minus sign. This whitespace will end the |
| preprocessing number. |
| |
| |
| File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: C++ Misunderstandings, Next: Non-bugs, Prev: Disappointments, Up: Trouble |
| |
| 11.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 |
| |
| |
| File: gcc.info, Node: Static Definitions, Next: Name lookup, Up: C++ Misunderstandings |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Name lookup, Next: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Temporaries, Next: Copy Assignment, Prev: Name lookup, Up: C++ Misunderstandings |
| |
| 11.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 ()); |
| |
| |
| File: gcc.info, Node: Copy Assignment, Prev: Temporaries, Up: C++ Misunderstandings |
| |
| 11.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. |
| |
| |
| File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: C++ Misunderstandings, Up: Trouble |
| |
| 11.9 Certain Changes We Don't Want to Make |
| ========================================== |
| |
| This section lists changes that people frequently request, but which we |
| do not make because we think GCC is better without them. |
| |
| * Checking the number and type of arguments to a function which has |
| an old-fashioned definition and no prototype. |
| |
| Such a feature would work only occasionally--only for calls that |
| appear in the same file as the called function, following the |
| definition. The only way to check all calls reliably is to add a |
| prototype for the function. But adding a prototype eliminates the |
| motivation for this feature. So the feature is not worthwhile. |
| |
| * Warning about using an expression whose type is signed as a shift |
| count. |
| |
| Shift count operands are probably signed more often than unsigned. |
| Warning about this would cause far more annoyance than good. |
| |
| * Warning about assigning a signed value to an unsigned variable. |
| |
| Such assignments must be very common; warning about them would |
| cause more annoyance than good. |
| |
| * Warning when a non-void function value is ignored. |
| |
| C contains many standard functions that return a value that most |
| programs choose to ignore. One obvious example is `printf'. |
| Warning about this practice only leads the defensive programmer to |
| clutter programs with dozens of casts to `void'. Such casts are |
| required so frequently that they become visual noise. Writing |
| those casts becomes so automatic that they no longer convey useful |
| information about the intentions of the programmer. For functions |
| where the return value should never be ignored, use the |
| `warn_unused_result' function attribute (*note Function |
| Attributes::). |
| |
| * Making `-fshort-enums' the default. |
| |
| This would cause storage layout to be incompatible with most other |
| C compilers. And it doesn't seem very important, given that you |
| can get the same result in other ways. The case where it matters |
| most is when the enumeration-valued object is inside a structure, |
| and in that case you can specify a field width explicitly. |
| |
| * Making bit-fields unsigned by default on particular machines where |
| "the ABI standard" says to do so. |
| |
| The ISO C standard leaves it up to the implementation whether a |
| bit-field declared plain `int' is signed or not. This in effect |
| creates two alternative dialects of C. |
| |
| The GNU C compiler supports both dialects; you can specify the |
| signed dialect with `-fsigned-bitfields' and the unsigned dialect |
| with `-funsigned-bitfields'. However, this leaves open the |
| question of which dialect to use by default. |
| |
| Currently, the preferred dialect makes plain bit-fields signed, |
| because this is simplest. Since `int' is the same as `signed int' |
| in every other context, it is cleanest for them to be the same in |
| bit-fields as well. |
| |
| Some computer manufacturers have published Application Binary |
| Interface standards which specify that plain bit-fields should be |
| unsigned. It is a mistake, however, to say anything about this |
| issue in an ABI. This is because the handling of plain bit-fields |
| distinguishes two dialects of C. Both dialects are meaningful on |
| every type of machine. Whether a particular object file was |
| compiled using signed bit-fields or unsigned is of no concern to |
| other object files, even if they access the same bit-fields in the |
| same data structures. |
| |
| A given program is written in one or the other of these two |
| dialects. The program stands a chance to work on most any machine |
| if it is compiled with the proper dialect. It is unlikely to work |
| at all if compiled with the wrong dialect. |
| |
| Many users appreciate the GNU C compiler because it provides an |
| environment that is uniform across machines. These users would be |
| inconvenienced if the compiler treated plain bit-fields |
| differently on certain machines. |
| |
| Occasionally users write programs intended only for a particular |
| machine type. On these occasions, the users would benefit if the |
| GNU C compiler were to support by default the same dialect as the |
| other compilers on that machine. But such applications are rare. |
| And users writing a program to run on more than one type of |
| machine cannot possibly benefit from this kind of compatibility. |
| |
| This is why GCC does and will treat plain bit-fields in the same |
| fashion on all types of machines (by default). |
| |
| There are some arguments for making bit-fields unsigned by default |
| on all machines. If, for example, this becomes a universal de |
| facto standard, it would make sense for GCC to go along with it. |
| This is something to be considered in the future. |
| |
| (Of course, users strongly concerned about portability should |
| indicate explicitly in each bit-field whether it is signed or not. |
| In this way, they write programs which have the same meaning in |
| both C dialects.) |
| |
| * Undefining `__STDC__' when `-ansi' is not used. |
| |
| Currently, GCC defines `__STDC__' unconditionally. This provides |
| good results in practice. |
| |
| Programmers normally use conditionals on `__STDC__' to ask whether |
| it is safe to use certain features of ISO C, such as function |
| prototypes or ISO token concatenation. Since plain `gcc' supports |
| all the features of ISO C, the correct answer to these questions is |
| "yes". |
| |
| Some users try to use `__STDC__' to check for the availability of |
| certain library facilities. This is actually incorrect usage in |
| an ISO C program, because the ISO C standard says that a conforming |
| freestanding implementation should define `__STDC__' even though it |
| does not have the library facilities. `gcc -ansi -pedantic' is a |
| conforming freestanding implementation, and it is therefore |
| required to define `__STDC__', even though it does not come with |
| an ISO C library. |
| |
| Sometimes people say that defining `__STDC__' in a compiler that |
| does not completely conform to the ISO C standard somehow violates |
| the standard. This is illogical. The standard is a standard for |
| compilers that claim to support ISO C, such as `gcc -ansi'--not |
| for other compilers such as plain `gcc'. Whatever the ISO C |
| standard says is relevant to the design of plain `gcc' without |
| `-ansi' only for pragmatic reasons, not as a requirement. |
| |
| GCC normally defines `__STDC__' to be 1, and in addition defines |
| `__STRICT_ANSI__' if you specify the `-ansi' option, or a `-std' |
| option for strict conformance to some version of ISO C. On some |
| hosts, system include files use a different convention, where |
| `__STDC__' is normally 0, but is 1 if the user specifies strict |
| conformance to the C Standard. GCC follows the host convention |
| when processing system include files, but when processing user |
| files it follows the usual GNU C convention. |
| |
| * Undefining `__STDC__' in C++. |
| |
| Programs written to compile with C++-to-C translators get the |
| value of `__STDC__' that goes with the C compiler that is |
| subsequently used. These programs must test `__STDC__' to |
| determine what kind of C preprocessor that compiler uses: whether |
| they should concatenate tokens in the ISO C fashion or in the |
| traditional fashion. |
| |
| These programs work properly with GNU C++ if `__STDC__' is defined. |
| They would not work otherwise. |
| |
| In addition, many header files are written to provide prototypes |
| in ISO C but not in traditional C. Many of these header files can |
| work without change in C++ provided `__STDC__' is defined. If |
| `__STDC__' is not defined, they will all fail, and will all need |
| to be changed to test explicitly for C++ as well. |
| |
| * Deleting "empty" loops. |
| |
| Historically, GCC has not deleted "empty" loops under the |
| assumption that the most likely reason you would put one in a |
| program is to have a delay, so deleting them will not make real |
| programs run any faster. |
| |
| However, the rationale here is that optimization of a nonempty loop |
| cannot produce an empty one. This held for carefully written C |
| compiled with less powerful optimizers but is not always the case |
| for carefully written C++ or with more powerful optimizers. Thus |
| GCC will remove operations from loops whenever it can determine |
| those operations are not externally visible (apart from the time |
| taken to execute them, of course). In case the loop can be proved |
| to be finite, GCC will also remove the loop itself. |
| |
| Be aware of this when performing timing tests, for instance the |
| following loop can be completely removed, provided |
| `some_expression' can provably not change any global state. |
| |
| { |
| int sum = 0; |
| int ix; |
| |
| for (ix = 0; ix != 10000; ix++) |
| sum += some_expression; |
| } |
| |
| Even though `sum' is accumulated in the loop, no use is made of |
| that summation, so the accumulation can be removed. |
| |
| * Making side effects happen in the same order as in some other |
| compiler. |
| |
| It is never safe to depend on the order of evaluation of side |
| effects. For example, a function call like this may very well |
| behave differently from one compiler to another: |
| |
| void func (int, int); |
| |
| int i = 2; |
| func (i++, i++); |
| |
| There is no guarantee (in either the C or the C++ standard language |
| definitions) that the increments will be evaluated in any |
| particular order. Either increment might happen first. `func' |
| might get the arguments `2, 3', or it might get `3, 2', or even |
| `2, 2'. |
| |
| * Making certain warnings into errors by default. |
| |
| Some ISO C testsuites report failure when the compiler does not |
| produce an error message for a certain program. |
| |
| ISO C requires a "diagnostic" message for certain kinds of invalid |
| programs, but a warning is defined by GCC to count as a |
| diagnostic. If GCC produces a warning but not an error, that is |
| correct ISO C support. If testsuites call this "failure", they |
| should be run with the GCC option `-pedantic-errors', which will |
| turn these warnings into errors. |
| |
| |
| |
| File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble |
| |
| 11.10 Warning Messages and Error Messages |
| ========================================= |
| |
| The GNU compiler can produce two kinds of diagnostics: errors and |
| warnings. Each kind has a different purpose: |
| |
| "Errors" report problems that make it impossible to compile your |
| program. GCC reports errors with the source file name and line |
| number where the problem is apparent. |
| |
| "Warnings" report other unusual conditions in your code that _may_ |
| indicate a problem, although compilation can (and does) proceed. |
| Warning messages also report the source file name and line number, |
| but include the text `warning:' to distinguish them from error |
| messages. |
| |
| Warnings may indicate danger points where you should check to make sure |
| that your program really does what you intend; or the use of obsolete |
| features; or the use of nonstandard features of GNU C or C++. Many |
| warnings are issued only if you ask for them, with one of the `-W' |
| options (for instance, `-Wall' requests a variety of useful warnings). |
| |
| GCC always tries to compile your program if possible; it never |
| gratuitously rejects a program whose meaning is clear merely because |
| (for instance) it fails to conform to a standard. In some cases, |
| however, the C and C++ standards specify that certain extensions are |
| forbidden, and a diagnostic _must_ be issued by a conforming compiler. |
| The `-pedantic' option tells GCC to issue warnings in such cases; |
| `-pedantic-errors' says to make them errors instead. This does not |
| mean that _all_ non-ISO constructs get warnings or errors. |
| |
| *Note Options to Request or Suppress Warnings: Warning Options, for |
| more detail on these and related command-line options. |
| |
| |
| File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top |
| |
| 12 Reporting Bugs |
| ***************** |
| |
| Your bug reports play an essential role in making GCC reliable. |
| |
| When you encounter a problem, the first thing to do is to see if it is |
| already known. *Note Trouble::. If it isn't known, then you should |
| report the problem. |
| |
| * Menu: |
| |
| * Criteria: Bug Criteria. Have you really found a bug? |
| * Reporting: Bug Reporting. How to report a bug effectively. |
| * Known: Trouble. Known problems. |
| * Help: Service. Where to ask for help. |
| |
| |
| File: gcc.info, Node: Bug Criteria, Next: Bug Reporting, Up: Bugs |
| |
| 12.1 Have You Found a Bug? |
| ========================== |
| |
| If you are not sure whether you have found a bug, here are some |
| guidelines: |
| |
| * If the compiler gets a fatal signal, for any input whatever, that |
| is a compiler bug. Reliable compilers never crash. |
| |
| * If the compiler produces invalid assembly code, for any input |
| whatever (except an `asm' statement), that is a compiler bug, |
| unless the compiler reports errors (not just warnings) which would |
| ordinarily prevent the assembler from being run. |
| |
| * If the compiler produces valid assembly code that does not |
| correctly execute the input source code, that is a compiler bug. |
| |
| However, you must double-check to make sure, because you may have a |
| program whose behavior is undefined, which happened by chance to |
| give the desired results with another C or C++ compiler. |
| |
| For example, in many nonoptimizing compilers, you can write `x;' |
| at the end of a function instead of `return x;', with the same |
| results. But the value of the function is undefined if `return' |
| is omitted; it is not a bug when GCC produces different results. |
| |
| Problems often result from expressions with two increment |
| operators, as in `f (*p++, *p++)'. Your previous compiler might |
| have interpreted that expression the way you intended; GCC might |
| interpret it another way. Neither compiler is wrong. The bug is |
| in your code. |
| |
| After you have localized the error to a single source line, it |
| should be easy to check for these things. If your program is |
| correct and well defined, you have found a compiler bug. |
| |
| * If the compiler produces an error message for valid input, that is |
| a compiler bug. |
| |
| * If the compiler does not produce an error message for invalid |
| input, that is a compiler bug. However, you should note that your |
| idea of "invalid input" might be someone else's idea of "an |
| extension" or "support for traditional practice". |
| |
| * If you are an experienced user of one of the languages GCC |
| supports, your suggestions for improvement of GCC are welcome in |
| any case. |
| |
| |
| File: gcc.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Bugs |
| |
| 12.2 How and where to Report Bugs |
| ================================= |
| |
| Bugs should be reported to the bug database at |
| `http://gcc.gnu.org/bugs.html'. |
| |
| |
| File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top |
| |
| 13 How To Get Help with GCC |
| *************************** |
| |
| If you need help installing, using or changing GCC, there are two ways |
| to find it: |
| |
| * Send a message to a suitable network mailing list. First try |
| <gcc-help@gcc.gnu.org> (for help installing or using GCC), and if |
| that brings no response, try <gcc@gcc.gnu.org>. For help changing |
| GCC, ask <gcc@gcc.gnu.org>. If you think you have found a bug in |
| GCC, please report it following the instructions at *note Bug |
| Reporting::. |
| |
| * Look in the service directory for someone who might help you for a |
| fee. The service directory is found at |
| `http://www.fsf.org/resources/service'. |
| |
| For further information, see `http://gcc.gnu.org/faq.html#support'. |
| |
| |
| File: gcc.info, Node: Contributing, Next: Funding, Prev: Service, Up: Top |
| |
| 14 Contributing to GCC Development |
| ********************************** |
| |
| If you would like to help pretest GCC releases to assure they work well, |
| current development sources are available by SVN (see |
| `http://gcc.gnu.org/svn.html'). Source and binary snapshots are also |
| available for FTP; see `http://gcc.gnu.org/snapshots.html'. |
| |
| If you would like to work on improvements to GCC, please read the |
| advice at these URLs: |
| |
| `http://gcc.gnu.org/contribute.html' |
| `http://gcc.gnu.org/contributewhy.html' |
| |
| for information on how to make useful contributions and avoid |
| duplication of effort. Suggested projects are listed at |
| `http://gcc.gnu.org/projects/'. |
| |
| |
| File: gcc.info, Node: Funding, Next: GNU Project, Prev: Contributing, Up: Top |
| |
| Funding Free Software |
| ********************* |
| |
| If you want to have more free software a few years from now, it makes |
| sense for you to help encourage people to contribute funds for its |
| development. The most effective approach known is to encourage |
| commercial redistributors to donate. |
| |
| Users of free software systems can boost the pace of development by |
| encouraging for-a-fee distributors to donate part of their selling price |
| to free software developers--the Free Software Foundation, and others. |
| |
| The way to convince distributors to do this is to demand it and expect |
| it from them. So when you compare distributors, judge them partly by |
| how much they give to free software development. Show distributors |
| they must compete to be the one who gives the most. |
| |
| To make this approach work, you must insist on numbers that you can |
| compare, such as, "We will donate ten dollars to the Frobnitz project |
| for each disk sold." Don't be satisfied with a vague promise, such as |
| "A portion of the profits are donated," since it doesn't give a basis |
| for comparison. |
| |
| Even a precise fraction "of the profits from this disk" is not very |
| meaningful, since creative accounting and unrelated business decisions |
| can greatly alter what fraction of the sales price counts as profit. |
| If the price you pay is $50, ten percent of the profit is probably less |
| than a dollar; it might be a few cents, or nothing at all. |
| |
| Some redistributors do development work themselves. This is useful |
| too; but to keep everyone honest, you need to inquire how much they do, |
| and what kind. Some kinds of development make much more long-term |
| difference than others. For example, maintaining a separate version of |
| a program contributes very little; maintaining the standard version of a |
| program for the whole community contributes much. Easy new ports |
| contribute little, since someone else would surely do them; difficult |
| ports such as adding a new CPU to the GNU Compiler Collection |
| contribute more; major new features or packages contribute the most. |
| |
| By establishing the idea that supporting further development is "the |
| proper thing to do" when distributing free software for a fee, we can |
| assure a steady flow of resources into making more free software. |
| |
| Copyright (C) 1994 Free Software Foundation, Inc. |
| Verbatim copying and redistribution of this section is permitted |
| without royalty; alteration is not permitted. |
| |
| |
| File: gcc.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top |
| |
| The GNU Project and GNU/Linux |
| ***************************** |
| |
| The GNU Project was launched in 1984 to develop a complete Unix-like |
| operating system which is free software: the GNU system. (GNU is a |
| recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) |
| Variants of the GNU operating system, which use the kernel Linux, are |
| now widely used; though these systems are often referred to as "Linux", |
| they are more accurately called GNU/Linux systems. |
| |
| For more information, see: |
| `http://www.gnu.org/' |
| `http://www.gnu.org/gnu/linux-and-gnu.html' |
| |
| |
| File: gcc.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top |
| |
| GNU General Public License |
| ************************** |
| |
| Version 3, 29 June 2007 |
| |
| Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' |
| |
| Everyone is permitted to copy and distribute verbatim copies of this |
| license document, but changing it is not allowed. |
| |
| Preamble |
| ======== |
| |
| The GNU General Public License is a free, copyleft license for software |
| and other kinds of works. |
| |
| The licenses for most software and other practical works are designed |
| to take away your freedom to share and change the works. By contrast, |
| the GNU General Public License is intended to guarantee your freedom to |
| share and change all versions of a program-to make sure it remains free |
| software for all its users. We, the Free Software Foundation, use the |
| GNU General Public License for most of our software; it applies also to |
| any other work released this way by its authors. You can apply it to |
| your programs, too. |
| |
| When we speak of free software, we are referring to freedom, not |
| price. Our General Public Licenses are designed to make sure that you |
| have the freedom to distribute copies of free software (and charge for |
| them if you wish), that you receive source code or can get it if you |
| want it, that you can change the software or use pieces of it in new |
| free programs, and that you know you can do these things. |
| |
| To protect your rights, we need to prevent others from denying you |
| these rights or asking you to surrender the rights. Therefore, you |
| have certain responsibilities if you distribute copies of the software, |
| or if you modify it: responsibilities to respect the freedom of others. |
| |
| For example, if you distribute copies of such a program, whether |
| gratis or for a fee, you must pass on to the recipients the same |
| freedoms that you received. You must make sure that they, too, receive |
| or can get the source code. And you must show them these terms so they |
| know their rights. |
| |
| Developers that use the GNU GPL protect your rights with two steps: |
| (1) assert copyright on the software, and (2) offer you this License |
| giving you legal permission to copy, distribute and/or modify it. |
| |
| For the developers' and authors' protection, the GPL clearly explains |
| that there is no warranty for this free software. For both users' and |
| authors' sake, the GPL requires that modified versions be marked as |
| changed, so that their problems will not be attributed erroneously to |
| authors of previous versions. |
| |
| Some devices are designed to deny users access to install or run |
| modified versions of the software inside them, although the |
| manufacturer can do so. This is fundamentally incompatible with the |
| aim of protecting users' freedom to change the software. The |
| systematic pattern of such abuse occurs in the area of products for |
| individuals to use, which is precisely where it is most unacceptable. |
| Therefore, we have designed this version of the GPL to prohibit the |
| practice for those products. If such problems arise substantially in |
| other domains, we stand ready to extend this provision to those domains |
| in future versions of the GPL, as needed to protect the freedom of |
| users. |
| |
| Finally, every program is threatened constantly by software patents. |
| States should not allow patents to restrict development and use of |
| software on general-purpose computers, but in those that do, we wish to |
| avoid the special danger that patents applied to a free program could |
| make it effectively proprietary. To prevent this, the GPL assures that |
| patents cannot be used to render the program non-free. |
| |
| The precise terms and conditions for copying, distribution and |
| modification follow. |
| |
| TERMS AND CONDITIONS |
| ==================== |
| |
| 0. Definitions. |
| |
| "This License" refers to version 3 of the GNU General Public |
| License. |
| |
| "Copyright" also means copyright-like laws that apply to other |
| kinds of works, such as semiconductor masks. |
| |
| "The Program" refers to any copyrightable work licensed under this |
| License. Each licensee is addressed as "you". "Licensees" and |
| "recipients" may be individuals or organizations. |
| |
| To "modify" a work means to copy from or adapt all or part of the |
| work in a fashion requiring copyright permission, other than the |
| making of an exact copy. The resulting work is called a "modified |
| version" of the earlier work or a work "based on" the earlier work. |
| |
| A "covered work" means either the unmodified Program or a work |
| based on the Program. |
| |
| To "propagate" a work means to do anything with it that, without |
| permission, would make you directly or secondarily liable for |
| infringement under applicable copyright law, except executing it |
| on a computer or modifying a private copy. Propagation includes |
| copying, distribution (with or without modification), making |
| available to the public, and in some countries other activities as |
| well. |
| |
| To "convey" a work means any kind of propagation that enables other |
| parties to make or receive copies. Mere interaction with a user |
| through a computer network, with no transfer of a copy, is not |
| conveying. |
| |
| An interactive user interface displays "Appropriate Legal Notices" |
| to the extent that it includes a convenient and prominently visible |
| feature that (1) displays an appropriate copyright notice, and (2) |
| tells the user that there is no warranty for the work (except to |
| the extent that warranties are provided), that licensees may |
| convey the work under this License, and how to view a copy of this |
| License. If the interface presents a list of user commands or |
| options, such as a menu, a prominent item in the list meets this |
| criterion. |
| |
| 1. Source Code. |
| |
| The "source code" for a work means the preferred form of the work |
| for making modifications to it. "Object code" means any |
| non-source form of a work. |
| |
| A "Standard Interface" means an interface that either is an |
| official standard defined by a recognized standards body, or, in |
| the case of interfaces specified for a particular programming |
| language, one that is widely used among developers working in that |
| language. |
| |
| The "System Libraries" of an executable work include anything, |
| other than the work as a whole, that (a) is included in the normal |
| form of packaging a Major Component, but which is not part of that |
| Major Component, and (b) serves only to enable use of the work |
| with that Major Component, or to implement a Standard Interface |
| for which an implementation is available to the public in source |
| code form. A "Major Component", in this context, means a major |
| essential component (kernel, window system, and so on) of the |
| specific operating system (if any) on which the executable work |
| runs, or a compiler used to produce the work, or an object code |
| interpreter used to run it. |
| |
| The "Corresponding Source" for a work in object code form means all |
| the source code needed to generate, install, and (for an executable |
| work) run the object code and to modify the work, including |
| scripts to control those activities. However, it does not include |
| the work's System Libraries, or general-purpose tools or generally |
| available free programs which are used unmodified in performing |
| those activities but which are not part of the work. For example, |
| Corresponding Source includes interface definition files |
| associated with source files for the work, and the source code for |
| shared libraries and dynamically linked subprograms that the work |
| is specifically designed to require, such as by intimate data |
| communication or control flow between those subprograms and other |
| parts of the work. |
| |
| The Corresponding Source need not include anything that users can |
| regenerate automatically from other parts of the Corresponding |
| Source. |
| |
| The Corresponding Source for a work in source code form is that |
| same work. |
| |
| 2. Basic Permissions. |
| |
| All rights granted under this License are granted for the term of |
| copyright on the Program, and are irrevocable provided the stated |
| conditions are met. This License explicitly affirms your unlimited |
| permission to run the unmodified Program. The output from running |
| a covered work is covered by this License only if the output, |
| given its content, constitutes a covered work. This License |
| acknowledges your rights of fair use or other equivalent, as |
| provided by copyright law. |
| |
| You may make, run and propagate covered works that you do not |
| convey, without conditions so long as your license otherwise |
| remains in force. You may convey covered works to others for the |
| sole purpose of having them make modifications exclusively for |
| you, or provide you with facilities for running those works, |
| provided that you comply with the terms of this License in |
| conveying all material for which you do not control copyright. |
| Those thus making or running the covered works for you must do so |
| exclusively on your behalf, under your direction and control, on |
| terms that prohibit them from making any copies of your |
| copyrighted material outside their relationship with you. |
| |
| Conveying under any other circumstances is permitted solely under |
| the conditions stated below. Sublicensing is not allowed; section |
| 10 makes it unnecessary. |
| |
| 3. Protecting Users' Legal Rights From Anti-Circumvention Law. |
| |
| No covered work shall be deemed part of an effective technological |
| measure under any applicable law fulfilling obligations under |
| article 11 of the WIPO copyright treaty adopted on 20 December |
| 1996, or similar laws prohibiting or restricting circumvention of |
| such measures. |
| |
| When you convey a covered work, you waive any legal power to forbid |
| circumvention of technological measures to the extent such |
| circumvention is effected by exercising rights under this License |
| with respect to the covered work, and you disclaim any intention |
| to limit operation or modification of the work as a means of |
| enforcing, against the work's users, your or third parties' legal |
| rights to forbid circumvention of technological measures. |
| |
| 4. Conveying Verbatim Copies. |
| |
| You may convey verbatim copies of the Program's source code as you |
| receive it, in any medium, provided that you conspicuously and |
| appropriately publish on each copy an appropriate copyright notice; |
| keep intact all notices stating that this License and any |
| non-permissive terms added in accord with section 7 apply to the |
| code; keep intact all notices of the absence of any warranty; and |
| give all recipients a copy of this License along with the Program. |
| |
| You may charge any price or no price for each copy that you convey, |
| and you may offer support or warranty protection for a fee. |
| |
| 5. Conveying Modified Source Versions. |
| |
| You may convey a work based on the Program, or the modifications to |
| produce it from the Program, in the form of source code under the |
| terms of section 4, provided that you also meet all of these |
| conditions: |
| |
| a. The work must carry prominent notices stating that you |
| modified it, and giving a relevant date. |
| |
| b. The work must carry prominent notices stating that it is |
| released under this License and any conditions added under |
| section 7. This requirement modifies the requirement in |
| section 4 to "keep intact all notices". |
| |
| c. You must license the entire work, as a whole, under this |
| License to anyone who comes into possession of a copy. This |
| License will therefore apply, along with any applicable |
| section 7 additional terms, to the whole of the work, and all |
| its parts, regardless of how they are packaged. This License |
| gives no permission to license the work in any other way, but |
| it does not invalidate such permission if you have separately |
| received it. |
| |
| d. If the work has interactive user interfaces, each must display |
| Appropriate Legal Notices; however, if the Program has |
| interactive interfaces that do not display Appropriate Legal |
| Notices, your work need not make them do so. |
| |
| A compilation of a covered work with other separate and independent |
| works, which are not by their nature extensions of the covered |
| work, and which are not combined with it such as to form a larger |
| program, in or on a volume of a storage or distribution medium, is |
| called an "aggregate" if the compilation and its resulting |
| copyright are not used to limit the access or legal rights of the |
| compilation's users beyond what the individual works permit. |
| Inclusion of a covered work in an aggregate does not cause this |
| License to apply to the other parts of the aggregate. |
| |
| 6. Conveying Non-Source Forms. |
| |
| You may convey a covered work in object code form under the terms |
| of sections 4 and 5, provided that you also convey the |
| machine-readable Corresponding Source under the terms of this |
| License, in one of these ways: |
| |
| a. Convey the object code in, or embodied in, a physical product |
| (including a physical distribution medium), accompanied by the |
| Corresponding Source fixed on a durable physical medium |
| customarily used for software interchange. |
| |
| b. Convey the object code in, or embodied in, a physical product |
| (including a physical distribution medium), accompanied by a |
| written offer, valid for at least three years and valid for |
| as long as you offer spare parts or customer support for that |
| product model, to give anyone who possesses the object code |
| either (1) a copy of the Corresponding Source for all the |
| software in the product that is covered by this License, on a |
| durable physical medium customarily used for software |
| interchange, for a price no more than your reasonable cost of |
| physically performing this conveying of source, or (2) access |
| to copy the Corresponding Source from a network server at no |
| charge. |
| |
| c. Convey individual copies of the object code with a copy of |
| the written offer to provide the Corresponding Source. This |
| alternative is allowed only occasionally and noncommercially, |
| and only if you received the object code with such an offer, |
| in accord with subsection 6b. |
| |
| d. Convey the object code by offering access from a designated |
| place (gratis or for a charge), and offer equivalent access |
| to the Corresponding Source in the same way through the same |
| place at no further charge. You need not require recipients |
| to copy the Corresponding Source along with the object code. |
| If the place to copy the object code is a network server, the |
| Corresponding Source may be on a different server (operated |
| by you or a third party) that supports equivalent copying |
| facilities, provided you maintain clear directions next to |
| the object code saying where to find the Corresponding Source. |
| Regardless of what server hosts the Corresponding Source, you |
| remain obligated to ensure that it is available for as long |
| as needed to satisfy these requirements. |
| |
| e. Convey the object code using peer-to-peer transmission, |
| provided you inform other peers where the object code and |
| Corresponding Source of the work are being offered to the |
| general public at no charge under subsection 6d. |
| |
| |
| A separable portion of the object code, whose source code is |
| excluded from the Corresponding Source as a System Library, need |
| not be included in conveying the object code work. |
| |
| A "User Product" is either (1) a "consumer product", which means |
| any tangible personal property which is normally used for personal, |
| family, or household purposes, or (2) anything designed or sold for |
| incorporation into a dwelling. In determining whether a product |
| is a consumer product, doubtful cases shall be resolved in favor of |
| coverage. For a particular product received by a particular user, |
| "normally used" refers to a typical or common use of that class of |
| product, regardless of the status of the particular user or of the |
| way in which the particular user actually uses, or expects or is |
| expected to use, the product. A product is a consumer product |
| regardless of whether the product has substantial commercial, |
| industrial or non-consumer uses, unless such uses represent the |
| only significant mode of use of the product. |
| |
| "Installation Information" for a User Product means any methods, |
| procedures, authorization keys, or other information required to |
| install and execute modified versions of a covered work in that |
| User Product from a modified version of its Corresponding Source. |
| The information must suffice to ensure that the continued |
| functioning of the modified object code is in no case prevented or |
| interfered with solely because modification has been made. |
| |
| If you convey an object code work under this section in, or with, |
| or specifically for use in, a User Product, and the conveying |
| occurs as part of a transaction in which the right of possession |
| and use of the User Product is transferred to the recipient in |
| perpetuity or for a fixed term (regardless of how the transaction |
| is characterized), the Corresponding Source conveyed under this |
| section must be accompanied by the Installation Information. But |
| this requirement does not apply if neither you nor any third party |
| retains the ability to install modified object code on the User |
| Product (for example, the work has been installed in ROM). |
| |
| The requirement to provide Installation Information does not |
| include a requirement to continue to provide support service, |
| warranty, or updates for a work that has been modified or |
| installed by the recipient, or for the User Product in which it |
| has been modified or installed. Access to a network may be denied |
| when the modification itself materially and adversely affects the |
| operation of the network or violates the rules and protocols for |
| communication across the network. |
| |
| Corresponding Source conveyed, and Installation Information |
| provided, in accord with this section must be in a format that is |
| publicly documented (and with an implementation available to the |
| public in source code form), and must require no special password |
| or key for unpacking, reading or copying. |
| |
| 7. Additional Terms. |
| |
| "Additional permissions" are terms that supplement the terms of |
| this License by making exceptions from one or more of its |
| conditions. Additional permissions that are applicable to the |
| entire Program shall be treated as though they were included in |
| this License, to the extent that they are valid under applicable |
| law. If additional permissions apply only to part of the Program, |
| that part may be used separately under those permissions, but the |
| entire Program remains governed by this License without regard to |
| the additional permissions. |
| |
| When you convey a copy of a covered work, you may at your option |
| remove any additional permissions from that copy, or from any part |
| of it. (Additional permissions may be written to require their own |
| removal in certain cases when you modify the work.) You may place |
| additional permissions on material, added by you to a covered work, |
| for which you have or can give appropriate copyright permission. |
| |
| Notwithstanding any other provision of this License, for material |
| you add to a covered work, you may (if authorized by the copyright |
| holders of that material) supplement the terms of this License |
| with terms: |
| |
| a. Disclaiming warranty or limiting liability differently from |
| the terms of sections 15 and 16 of this License; or |
| |
| b. Requiring preservation of specified reasonable legal notices |
| or author attributions in that material or in the Appropriate |
| Legal Notices displayed by works containing it; or |
| |
| c. Prohibiting misrepresentation of the origin of that material, |
| or requiring that modified versions of such material be |
| marked in reasonable ways as different from the original |
| version; or |
| |
| d. Limiting the use for publicity purposes of names of licensors |
| or authors of the material; or |
| |
| e. Declining to grant rights under trademark law for use of some |
| trade names, trademarks, or service marks; or |
| |
| f. Requiring indemnification of licensors and authors of that |
| material by anyone who conveys the material (or modified |
| versions of it) with contractual assumptions of liability to |
| the recipient, for any liability that these contractual |
| assumptions directly impose on those licensors and authors. |
| |
| All other non-permissive additional terms are considered "further |
| restrictions" within the meaning of section 10. If the Program as |
| you received it, or any part of it, contains a notice stating that |
| it is governed by this License along with a term that is a further |
| restriction, you may remove that term. If a license document |
| contains a further restriction but permits relicensing or |
| conveying under this License, you may add to a covered work |
| material governed by the terms of that license document, provided |
| that the further restriction does not survive such relicensing or |
| conveying. |
| |
| If you add terms to a covered work in accord with this section, you |
| must place, in the relevant source files, a statement of the |
| additional terms that apply to those files, or a notice indicating |
| where to find the applicable terms. |
| |
| Additional terms, permissive or non-permissive, may be stated in |
| the form of a separately written license, or stated as exceptions; |
| the above requirements apply either way. |
| |
| 8. Termination. |
| |
| You may not propagate or modify a covered work except as expressly |
| provided under this License. Any attempt otherwise to propagate or |
| modify it is void, and will automatically terminate your rights |
| under this License (including any patent licenses granted under |
| the third paragraph of section 11). |
| |
| However, if you cease all violation of this License, then your |
| license from a particular copyright holder is reinstated (a) |
| provisionally, unless and until the copyright holder explicitly |
| and finally terminates your license, and (b) permanently, if the |
| copyright holder fails to notify you of the violation by some |
| reasonable means prior to 60 days after the cessation. |
| |
| Moreover, your license from a particular copyright holder is |
| reinstated permanently if the copyright holder notifies you of the |
| violation by some reasonable means, this is the first time you have |
| received notice of violation of this License (for any work) from |
| that copyright holder, and you cure the violation prior to 30 days |
| after your receipt of the notice. |
| |
| Termination of your rights under this section does not terminate |
| the licenses of parties who have received copies or rights from |
| you under this License. If your rights have been terminated and |
| not permanently reinstated, you do not qualify to receive new |
| licenses for the same material under section 10. |
| |
| 9. Acceptance Not Required for Having Copies. |
| |
| You are not required to accept this License in order to receive or |
| run a copy of the Program. Ancillary propagation of a covered work |
| occurring solely as a consequence of using peer-to-peer |
| transmission to receive a copy likewise does not require |
| acceptance. However, nothing other than this License grants you |
| permission to propagate or modify any covered work. These actions |
| infringe copyright if you do not accept this License. Therefore, |
| by modifying or propagating a covered work, you indicate your |
| acceptance of this License to do so. |
| |
| 10. Automatic Licensing of Downstream Recipients. |
| |
| Each time you convey a covered work, the recipient automatically |
| receives a license from the original licensors, to run, modify and |
| propagate that work, subject to this License. You are not |
| responsible for enforcing compliance by third parties with this |
| License. |
| |
| An "entity transaction" is a transaction transferring control of an |
| organization, or substantially all assets of one, or subdividing an |
| organization, or merging organizations. If propagation of a |
| covered work results from an entity transaction, each party to that |
| transaction who receives a copy of the work also receives whatever |
| licenses to the work the party's predecessor in interest had or |
| could give under the previous paragraph, plus a right to |
| possession of the Corresponding Source of the work from the |
| predecessor in interest, if the predecessor has it or can get it |
| with reasonable efforts. |
| |
| You may not impose any further restrictions on the exercise of the |
| rights granted or affirmed under this License. For example, you |
| may not impose a license fee, royalty, or other charge for |
| exercise of rights granted under this License, and you may not |
| initiate litigation (including a cross-claim or counterclaim in a |
| lawsuit) alleging that any patent claim is infringed by making, |
| using, selling, offering for sale, or importing the Program or any |
| portion of it. |
| |
| 11. Patents. |
| |
| A "contributor" is a copyright holder who authorizes use under this |
| License of the Program or a work on which the Program is based. |
| The work thus licensed is called the contributor's "contributor |
| version". |
| |
| A contributor's "essential patent claims" are all patent claims |
| owned or controlled by the contributor, whether already acquired or |
| hereafter acquired, that would be infringed by some manner, |
| permitted by this License, of making, using, or selling its |
| contributor version, but do not include claims that would be |
| infringed only as a consequence of further modification of the |
| contributor version. For purposes of this definition, "control" |
| includes the right to grant patent sublicenses in a manner |
| consistent with the requirements of this License. |
| |
| Each contributor grants you a non-exclusive, worldwide, |
| royalty-free patent license under the contributor's essential |
| patent claims, to make, use, sell, offer for sale, import and |
| otherwise run, modify and propagate the contents of its |
| contributor version. |
| |
| In the following three paragraphs, a "patent license" is any |
| express agreement or commitment, however denominated, not to |
| enforce a patent (such as an express permission to practice a |
| patent or covenant not to sue for patent infringement). To |
| "grant" such a patent license to a party means to make such an |
| agreement or commitment not to enforce a patent against the party. |
| |
| If you convey a covered work, knowingly relying on a patent |
| license, and the Corresponding Source of the work is not available |
| for anyone to copy, free of charge and under the terms of this |
| License, through a publicly available network server or other |
| readily accessible means, then you must either (1) cause the |
| Corresponding Source to be so available, or (2) arrange to deprive |
| yourself of the benefit of the patent license for this particular |
| work, or (3) arrange, in a manner consistent with the requirements |
| of this License, to extend the patent license to downstream |
| recipients. "Knowingly relying" means you have actual knowledge |
| that, but for the patent license, your conveying the covered work |
| in a country, or your recipient's use of the covered work in a |
| country, would infringe one or more identifiable patents in that |
| country that you have reason to believe are valid. |
| |
| If, pursuant to or in connection with a single transaction or |
| arrangement, you convey, or propagate by procuring conveyance of, a |
| covered work, and grant a patent license to some of the parties |
| receiving the covered work authorizing them to use, propagate, |
| modify or convey a specific copy of the covered work, then the |
| patent license you grant is automatically extended to all |
| recipients of the covered work and works based on it. |
| |
| A patent license is "discriminatory" if it does not include within |
| the scope of its coverage, prohibits the exercise of, or is |
| conditioned on the non-exercise of one or more of the rights that |
| are specifically granted under this License. You may not convey a |
| covered work if you are a party to an arrangement with a third |
| party that is in the business of distributing software, under |
| which you make payment to the third party based on the extent of |
| your activity of conveying the work, and under which the third |
| party grants, to any of the parties who would receive the covered |
| work from you, a discriminatory patent license (a) in connection |
| with copies of the covered work conveyed by you (or copies made |
| from those copies), or (b) primarily for and in connection with |
| specific products or compilations that contain the covered work, |
| unless you entered into that arrangement, or that patent license |
| was granted, prior to 28 March 2007. |
| |
| Nothing in this License shall be construed as excluding or limiting |
| any implied license or other defenses to infringement that may |
| otherwise be available to you under applicable patent law. |
| |
| 12. No Surrender of Others' Freedom. |
| |
| If conditions are imposed on you (whether by court order, |
| agreement or otherwise) that contradict the conditions of this |
| License, they do not excuse you from the conditions of this |
| License. If you cannot convey a covered work so as to satisfy |
| simultaneously your obligations under this License and any other |
| pertinent obligations, then as a consequence you may not convey it |
| at all. For example, if you agree to terms that obligate you to |
| collect a royalty for further conveying from those to whom you |
| convey the Program, the only way you could satisfy both those |
| terms and this License would be to refrain entirely from conveying |
| the Program. |
| |
| 13. Use with the GNU Affero General Public License. |
| |
| Notwithstanding any other provision of this License, you have |
| permission to link or combine any covered work with a work licensed |
| under version 3 of the GNU Affero General Public License into a |
| single combined work, and to convey the resulting work. The terms |
| of this License will continue to apply to the part which is the |
| covered work, but the special requirements of the GNU Affero |
| General Public License, section 13, concerning interaction through |
| a network will apply to the combination as such. |
| |
| 14. Revised Versions of this License. |
| |
| The Free Software Foundation may publish revised and/or new |
| versions of the GNU General Public License from time to time. |
| Such new versions will be similar in spirit to the present |
| version, but may differ in detail to address new problems or |
| concerns. |
| |
| Each version is given a distinguishing version number. If the |
| Program specifies that a certain numbered version of the GNU |
| General Public License "or any later version" applies to it, you |
| have the option of following the terms and conditions either of |
| that numbered version or of any later version published by the |
| Free Software Foundation. If the Program does not specify a |
| version number of the GNU General Public License, you may choose |
| any version ever published by the Free Software Foundation. |
| |
| If the Program specifies that a proxy can decide which future |
| versions of the GNU General Public License can be used, that |
| proxy's public statement of acceptance of a version permanently |
| authorizes you to choose that version for the Program. |
| |
| Later license versions may give you additional or different |
| permissions. However, no additional obligations are imposed on any |
| author or copyright holder as a result of your choosing to follow a |
| later version. |
| |
| 15. Disclaimer of Warranty. |
| |
| THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY |
| APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE |
| COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" |
| WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, |
| INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF |
| MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE |
| RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. |
| SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL |
| NECESSARY SERVICING, REPAIR OR CORRECTION. |
| |
| 16. Limitation of Liability. |
| |
| IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN |
| WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES |
| AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU |
| FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR |
| CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE |
| THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA |
| BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD |
| PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER |
| PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF |
| THE POSSIBILITY OF SUCH DAMAGES. |
| |
| 17. Interpretation of Sections 15 and 16. |
| |
| If the disclaimer of warranty and limitation of liability provided |
| above cannot be given local legal effect according to their terms, |
| reviewing courts shall apply local law that most closely |
| approximates an absolute waiver of all civil liability in |
| connection with the Program, unless a warranty or assumption of |
| liability accompanies a copy of the Program in return for a fee. |
| |
| |
| END OF TERMS AND CONDITIONS |
| =========================== |
| |
| How to Apply These Terms to Your New Programs |
| ============================================= |
| |
| If you develop a new program, and you want it to be of the greatest |
| possible use to the public, the best way to achieve this is to make it |
| free software which everyone can redistribute and change under these |
| terms. |
| |
| To do so, attach the following notices to the program. It is safest |
| to attach them to the start of each source file to most effectively |
| state the exclusion of warranty; and each file should have at least the |
| "copyright" line and a pointer to where the full notice is found. |
| |
| ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. |
| Copyright (C) YEAR NAME OF AUTHOR |
| |
| This program is free software: you can redistribute it and/or modify |
| it under the terms of the GNU General Public License as published by |
| the Free Software Foundation, either version 3 of the License, or (at |
| your option) any later version. |
| |
| This program is distributed in the hope that it will be useful, but |
| WITHOUT ANY WARRANTY; without even the implied warranty of |
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| General Public License for more details. |
| |
| You should have received a copy of the GNU General Public License |
| along with this program. If not, see `http://www.gnu.org/licenses/'. |
| |
| Also add information on how to contact you by electronic and paper |
| mail. |
| |
| If the program does terminal interaction, make it output a short |
| notice like this when it starts in an interactive mode: |
| |
| PROGRAM Copyright (C) YEAR NAME OF AUTHOR |
| This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. |
| This is free software, and you are welcome to redistribute it |
| under certain conditions; type `show c' for details. |
| |
| The hypothetical commands `show w' and `show c' should show the |
| appropriate parts of the General Public License. Of course, your |
| program's commands might be different; for a GUI interface, you would |
| use an "about box". |
| |
| You should also get your employer (if you work as a programmer) or |
| school, if any, to sign a "copyright disclaimer" for the program, if |
| necessary. For more information on this, and how to apply and follow |
| the GNU GPL, see `http://www.gnu.org/licenses/'. |
| |
| The GNU General Public License does not permit incorporating your |
| program into proprietary programs. If your program is a subroutine |
| library, you may consider it more useful to permit linking proprietary |
| applications with the library. If this is what you want to do, use the |
| GNU Lesser General Public License instead of this License. But first, |
| please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. |
| |
| |
| File: gcc.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top |
| |
| GNU Free Documentation License |
| ****************************** |
| |
| Version 1.3, 3 November 2008 |
| |
| Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. |
| `http://fsf.org/' |
| |
| Everyone is permitted to copy and distribute verbatim copies |
| of this license document, but changing it is not allowed. |
| |
| 0. PREAMBLE |
| |
| The purpose of this License is to make a manual, textbook, or other |
| functional and useful document "free" in the sense of freedom: to |
| assure everyone the effective freedom to copy and redistribute it, |
| with or without modifying it, either commercially or |
| noncommercially. Secondarily, this License preserves for the |
| author and publisher a way to get credit for their work, while not |
| being considered responsible for modifications made by others. |
| |
| This License is a kind of "copyleft", which means that derivative |
| works of the document must themselves be free in the same sense. |
| It complements the GNU General Public License, which is a copyleft |
| license designed for free software. |
| |
| We have designed this License in order to use it for manuals for |
| free software, because free software needs free documentation: a |
| free program should come with manuals providing the same freedoms |
| that the software does. But this License is not limited to |
| software manuals; it can be used for any textual work, regardless |
| of subject matter or whether it is published as a printed book. |
| We recommend this License principally for works whose purpose is |
| instruction or reference. |
| |
| 1. APPLICABILITY AND DEFINITIONS |
| |
| This License applies to any manual or other work, in any medium, |
| that contains a notice placed by the copyright holder saying it |
| can be distributed under the terms of this License. Such a notice |
| grants a world-wide, royalty-free license, unlimited in duration, |
| to use that work under the conditions stated herein. The |
| "Document", below, refers to any such manual or work. Any member |
| of the public is a licensee, and is addressed as "you". You |
| accept the license if you copy, modify or distribute the work in a |
| way requiring permission under copyright law. |
| |
| A "Modified Version" of the Document means any work containing the |
| Document or a portion of it, either copied verbatim, or with |
| modifications and/or translated into another language. |
| |
| A "Secondary Section" is a named appendix or a front-matter section |
| of the Document that deals exclusively with the relationship of the |
| publishers or authors of the Document to the Document's overall |
| subject (or to related matters) and contains nothing that could |
| fall directly within that overall subject. (Thus, if the Document |
| is in part a textbook of mathematics, a Secondary Section may not |
| explain any mathematics.) The relationship could be a matter of |
| historical connection with the subject or with related matters, or |
| of legal, commercial, philosophical, ethical or political position |
| regarding them. |
| |
| The "Invariant Sections" are certain Secondary Sections whose |
| titles are designated, as being those of Invariant Sections, in |
| the notice that says that the Document is released under this |
| License. If a section does not fit the above definition of |
| Secondary then it is not allowed to be designated as Invariant. |
| The Document may contain zero Invariant Sections. If the Document |
| does not identify any Invariant Sections then there are none. |
| |
| The "Cover Texts" are certain short passages of text that are |
| listed, as Front-Cover Texts or Back-Cover Texts, in the notice |
| that says that the Document is released under this License. A |
| Front-Cover Text may be at most 5 words, and a Back-Cover Text may |
| be at most 25 words. |
| |
| A "Transparent" copy of the Document means a machine-readable copy, |
| represented in a format whose specification is available to the |
| general public, that is suitable for revising the document |
| straightforwardly with generic text editors or (for images |
| composed of pixels) generic paint programs or (for drawings) some |
| widely available drawing editor, and that is suitable for input to |
| text formatters or for automatic translation to a variety of |
| formats suitable for input to text formatters. A copy made in an |
| otherwise Transparent file format whose markup, or absence of |
| markup, has been arranged to thwart or discourage subsequent |
| modification by readers is not Transparent. An image format is |
| not Transparent if used for any substantial amount of text. A |
| copy that is not "Transparent" is called "Opaque". |
| |
| Examples of suitable formats for Transparent copies include plain |
| ASCII without markup, Texinfo input format, LaTeX input format, |
| SGML or XML using a publicly available DTD, and |
| standard-conforming simple HTML, PostScript or PDF designed for |
| human modification. Examples of transparent image formats include |
| PNG, XCF and JPG. Opaque formats include proprietary formats that |
| can be read and edited only by proprietary word processors, SGML or |
| XML for which the DTD and/or processing tools are not generally |
| available, and the machine-generated HTML, PostScript or PDF |
| produced by some word processors for output purposes only. |
| |
| The "Title Page" means, for a printed book, the title page itself, |
| plus such following pages as are needed to hold, legibly, the |
| material this License requires to appear in the title page. For |
| works in formats which do not have any title page as such, "Title |
| Page" means the text near the most prominent appearance of the |
| work's title, preceding the beginning of the body of the text. |
| |
| The "publisher" means any person or entity that distributes copies |
| of the Document to the public. |
| |
| A section "Entitled XYZ" means a named subunit of the Document |
| whose title either is precisely XYZ or contains XYZ in parentheses |
| following text that translates XYZ in another language. (Here XYZ |
| stands for a specific section name mentioned below, such as |
| "Acknowledgements", "Dedications", "Endorsements", or "History".) |
| To "Preserve the Title" of such a section when you modify the |
| Document means that it remains a section "Entitled XYZ" according |
| to this definition. |
| |
| The Document may include Warranty Disclaimers next to the notice |
| which states that this License applies to the Document. These |
| Warranty Disclaimers are considered to be included by reference in |
| this License, but only as regards disclaiming warranties: any other |
| implication that these Warranty Disclaimers may have is void and |
| has no effect on the meaning of this License. |
| |
| 2. VERBATIM COPYING |
| |
| You may copy and distribute the Document in any medium, either |
| commercially or noncommercially, provided that this License, the |
| copyright notices, and the license notice saying this License |
| applies to the Document are reproduced in all copies, and that you |
| add no other conditions whatsoever to those of this License. You |
| may not use technical measures to obstruct or control the reading |
| or further copying of the copies you make or distribute. However, |
| you may accept compensation in exchange for copies. If you |
| distribute a large enough number of copies you must also follow |
| the conditions in section 3. |
| |
| You may also lend copies, under the same conditions stated above, |
| and you may publicly display copies. |
| |
| 3. COPYING IN QUANTITY |
| |
| If you publish printed copies (or copies in media that commonly |
| have printed covers) of the Document, numbering more than 100, and |
| the Document's license notice requires Cover Texts, you must |
| enclose the copies in covers that carry, clearly and legibly, all |
| these Cover Texts: Front-Cover Texts on the front cover, and |
| Back-Cover Texts on the back cover. Both covers must also clearly |
| and legibly identify you as the publisher of these copies. The |
| front cover must present the full title with all words of the |
| title equally prominent and visible. You may add other material |
| on the covers in addition. Copying with changes limited to the |
| covers, as long as they preserve the title of the Document and |
| satisfy these conditions, can be treated as verbatim copying in |
| other respects. |
| |
| If the required texts for either cover are too voluminous to fit |
| legibly, you should put the first ones listed (as many as fit |
| reasonably) on the actual cover, and continue the rest onto |
| adjacent pages. |
| |
| If you publish or distribute Opaque copies of the Document |
| numbering more than 100, you must either include a |
| machine-readable Transparent copy along with each Opaque copy, or |
| state in or with each Opaque copy a computer-network location from |
| which the general network-using public has access to download |
| using public-standard network protocols a complete Transparent |
| copy of the Document, free of added material. If you use the |
| latter option, you must take reasonably prudent steps, when you |
| begin distribution of Opaque copies in quantity, to ensure that |
| this Transparent copy will remain thus accessible at the stated |
| location until at least one year after the last time you |
| distribute an Opaque copy (directly or through your agents or |
| retailers) of that edition to the public. |
| |
| It is requested, but not required, that you contact the authors of |
| the Document well before redistributing any large number of |
| copies, to give them a chance to provide you with an updated |
| version of the Document. |
| |
| 4. MODIFICATIONS |
| |
| You may copy and distribute a Modified Version of the Document |
| under the conditions of sections 2 and 3 above, provided that you |
| release the Modified Version under precisely this License, with |
| the Modified Version filling the role of the Document, thus |
| licensing distribution and modification of the Modified Version to |
| whoever possesses a copy of it. In addition, you must do these |
| things in the Modified Version: |
| |
| A. Use in the Title Page (and on the covers, if any) a title |
| distinct from that of the Document, and from those of |
| previous versions (which should, if there were any, be listed |
| in the History section of the Document). You may use the |
| same title as a previous version if the original publisher of |
| that version gives permission. |
| |
| B. List on the Title Page, as authors, one or more persons or |
| entities responsible for authorship of the modifications in |
| the Modified Version, together with at least five of the |
| principal authors of the Document (all of its principal |
| authors, if it has fewer than five), unless they release you |
| from this requirement. |
| |
| C. State on the Title page the name of the publisher of the |
| Modified Version, as the publisher. |
| |
| D. Preserve all the copyright notices of the Document. |
| |
| E. Add an appropriate copyright notice for your modifications |
| adjacent to the other copyright notices. |
| |
| F. Include, immediately after the copyright notices, a license |
| notice giving the public permission to use the Modified |
| Version under the terms of this License, in the form shown in |
| the Addendum below. |
| |
| G. Preserve in that license notice the full lists of Invariant |
| Sections and required Cover Texts given in the Document's |
| license notice. |
| |
| H. Include an unaltered copy of this License. |
| |
| I. Preserve the section Entitled "History", Preserve its Title, |
| and add to it an item stating at least the title, year, new |
| authors, and publisher of the Modified Version as given on |
| the Title Page. If there is no section Entitled "History" in |
| the Document, create one stating the title, year, authors, |
| and publisher of the Document as given on its Title Page, |
| then add an item describing the Modified Version as stated in |
| the previous sentence. |
| |
| J. Preserve the network location, if any, given in the Document |
| for public access to a Transparent copy of the Document, and |
| likewise the network locations given in the Document for |
| previous versions it was based on. These may be placed in |
| the "History" section. You may omit a network location for a |
| work that was published at least four years before the |
| Document itself, or if the original publisher of the version |
| it refers to gives permission. |
| |
| K. For any section Entitled "Acknowledgements" or "Dedications", |
| Preserve the Title of the section, and preserve in the |
| section all the substance and tone of each of the contributor |
| acknowledgements and/or dedications given therein. |
| |
| L. Preserve all the Invariant Sections of the Document, |
| unaltered in their text and in their titles. Section numbers |
| or the equivalent are not considered part of the section |
| titles. |
| |
| M. Delete any section Entitled "Endorsements". Such a section |
| may not be included in the Modified Version. |
| |
| N. Do not retitle any existing section to be Entitled |
| "Endorsements" or to conflict in title with any Invariant |
| Section. |
| |
| O. Preserve any Warranty Disclaimers. |
| |
| If the Modified Version includes new front-matter sections or |
| appendices that qualify as Secondary Sections and contain no |
| material copied from the Document, you may at your option |
| designate some or all of these sections as invariant. To do this, |
| add their titles to the list of Invariant Sections in the Modified |
| Version's license notice. These titles must be distinct from any |
| other section titles. |
| |
| You may add a section Entitled "Endorsements", provided it contains |
| nothing but endorsements of your Modified Version by various |
| parties--for example, statements of peer review or that the text |
| has been approved by an organization as the authoritative |
| definition of a standard. |
| |
| You may add a passage of up to five words as a Front-Cover Text, |
| and a passage of up to 25 words as a Back-Cover Text, to the end |
| of the list of Cover Texts in the Modified Version. Only one |
| passage of Front-Cover Text and one of Back-Cover Text may be |
| added by (or through arrangements made by) any one entity. If the |
| Document already includes a cover text for the same cover, |
| previously added by you or by arrangement made by the same entity |
| you are acting on behalf of, you may not add another; but you may |
| replace the old one, on explicit permission from the previous |
| publisher that added the old one. |
| |
| The author(s) and publisher(s) of the Document do not by this |
| License give permission to use their names for publicity for or to |
| assert or imply endorsement of any Modified Version. |
| |
| 5. COMBINING DOCUMENTS |
| |
| You may combine the Document with other documents released under |
| this License, under the terms defined in section 4 above for |
| modified versions, provided that you include in the combination |
| all of the Invariant Sections of all of the original documents, |
| unmodified, and list them all as Invariant Sections of your |
| combined work in its license notice, and that you preserve all |
| their Warranty Disclaimers. |
| |
| The combined work need only contain one copy of this License, and |
| multiple identical Invariant Sections may be replaced with a single |
| copy. If there are multiple Invariant Sections with the same name |
| but different contents, make the title of each such section unique |
| by adding at the end of it, in parentheses, the name of the |
| original author or publisher of that section if known, or else a |
| unique number. Make the same adjustment to the section titles in |
| the list of Invariant Sections in the license notice of the |
| combined work. |
| |
| In the combination, you must combine any sections Entitled |
| "History" in the various original documents, forming one section |
| Entitled "History"; likewise combine any sections Entitled |
| "Acknowledgements", and any sections Entitled "Dedications". You |
| must delete all sections Entitled "Endorsements." |
| |
| 6. COLLECTIONS OF DOCUMENTS |
| |
| You may make a collection consisting of the Document and other |
| documents released under this License, and replace the individual |
| copies of this License in the various documents with a single copy |
| that is included in the collection, provided that you follow the |
| rules of this License for verbatim copying of each of the |
| documents in all other respects. |
| |
| You may extract a single document from such a collection, and |
| distribute it individually under this License, provided you insert |
| a copy of this License into the extracted document, and follow |
| this License in all other respects regarding verbatim copying of |
| that document. |
| |
| 7. AGGREGATION WITH INDEPENDENT WORKS |
| |
| A compilation of the Document or its derivatives with other |
| separate and independent documents or works, in or on a volume of |
| a storage or distribution medium, is called an "aggregate" if the |
| copyright resulting from the compilation is not used to limit the |
| legal rights of the compilation's users beyond what the individual |
| works permit. When the Document is included in an aggregate, this |
| License does not apply to the other works in the aggregate which |
| are not themselves derivative works of the Document. |
| |
| If the Cover Text requirement of section 3 is applicable to these |
| copies of the Document, then if the Document is less than one half |
| of the entire aggregate, the Document's Cover Texts may be placed |
| on covers that bracket the Document within the aggregate, or the |
| electronic equivalent of covers if the Document is in electronic |
| form. Otherwise they must appear on printed covers that bracket |
| the whole aggregate. |
| |
| 8. TRANSLATION |
| |
| Translation is considered a kind of modification, so you may |
| distribute translations of the Document under the terms of section |
| 4. Replacing Invariant Sections with translations requires special |
| permission from their copyright holders, but you may include |
| translations of some or all Invariant Sections in addition to the |
| original versions of these Invariant Sections. You may include a |
| translation of this License, and all the license notices in the |
| Document, and any Warranty Disclaimers, provided that you also |
| include the original English version of this License and the |
| original versions of those notices and disclaimers. In case of a |
| disagreement between the translation and the original version of |
| this License or a notice or disclaimer, the original version will |
| prevail. |
| |
| If a section in the Document is Entitled "Acknowledgements", |
| "Dedications", or "History", the requirement (section 4) to |
| Preserve its Title (section 1) will typically require changing the |
| actual title. |
| |
| 9. TERMINATION |
| |
| You may not copy, modify, sublicense, or distribute the Document |
| except as expressly provided under this License. Any attempt |
| otherwise to copy, modify, sublicense, or distribute it is void, |
| and will automatically terminate your rights under this License. |
| |
| However, if you cease all violation of this License, then your |
| license from a particular copyright holder is reinstated (a) |
| provisionally, unless and until the copyright holder explicitly |
| and finally terminates your license, and (b) permanently, if the |
| copyright holder fails to notify you of the violation by some |
| reasonable means prior to 60 days after the cessation. |
| |
| Moreover, your license from a particular copyright holder is |
| reinstated permanently if the copyright holder notifies you of the |
| violation by some reasonable means, this is the first time you have |
| received notice of violation of this License (for any work) from |
| that copyright holder, and you cure the violation prior to 30 days |
| after your receipt of the notice. |
| |
| Termination of your rights under this section does not terminate |
| the licenses of parties who have received copies or rights from |
| you under this License. If your rights have been terminated and |
| not permanently reinstated, receipt of a copy of some or all of |
| the same material does not give you any rights to use it. |
| |
| 10. FUTURE REVISIONS OF THIS LICENSE |
| |
| The Free Software Foundation may publish new, revised versions of |
| the GNU Free Documentation License from time to time. Such new |
| versions will be similar in spirit to the present version, but may |
| differ in detail to address new problems or concerns. See |
| `http://www.gnu.org/copyleft/'. |
| |
| Each version of the License is given a distinguishing version |
| number. If the Document specifies that a particular numbered |
| version of this License "or any later version" applies to it, you |
| have the option of following the terms and conditions either of |
| that specified version or of any later version that has been |
| published (not as a draft) by the Free Software Foundation. If |
| the Document does not specify a version number of this License, |
| you may choose any version ever published (not as a draft) by the |
| Free Software Foundation. If the Document specifies that a proxy |
| can decide which future versions of this License can be used, that |
| proxy's public statement of acceptance of a version permanently |
| authorizes you to choose that version for the Document. |
| |
| 11. RELICENSING |
| |
| "Massive Multiauthor Collaboration Site" (or "MMC Site") means any |
| World Wide Web server that publishes copyrightable works and also |
| provides prominent facilities for anybody to edit those works. A |
| public wiki that anybody can edit is an example of such a server. |
| A "Massive Multiauthor Collaboration" (or "MMC") contained in the |
| site means any set of copyrightable works thus published on the MMC |
| site. |
| |
| "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 |
| license published by Creative Commons Corporation, a not-for-profit |
| corporation with a principal place of business in San Francisco, |
| California, as well as future copyleft versions of that license |
| published by that same organization. |
| |
| "Incorporate" means to publish or republish a Document, in whole or |
| in part, as part of another Document. |
| |
| An MMC is "eligible for relicensing" if it is licensed under this |
| License, and if all works that were first published under this |
| License somewhere other than this MMC, and subsequently |
| incorporated in whole or in part into the MMC, (1) had no cover |
| texts or invariant sections, and (2) were thus incorporated prior |
| to November 1, 2008. |
| |
| The operator of an MMC Site may republish an MMC contained in the |
| site under CC-BY-SA on the same site at any time before August 1, |
| 2009, provided the MMC is eligible for relicensing. |
| |
| |
| ADDENDUM: How to use this License for your documents |
| ==================================================== |
| |
| To use this License in a document you have written, include a copy of |
| the License in the document and put the following copyright and license |
| notices just after the title page: |
| |
| Copyright (C) YEAR YOUR NAME. |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 |
| or any later version published by the Free Software Foundation; |
| with no Invariant Sections, no Front-Cover Texts, and no Back-Cover |
| Texts. A copy of the license is included in the section entitled ``GNU |
| Free Documentation License''. |
| |
| If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, |
| replace the "with...Texts." line with this: |
| |
| with the Invariant Sections being LIST THEIR TITLES, with |
| the Front-Cover Texts being LIST, and with the Back-Cover Texts |
| being LIST. |
| |
| If you have Invariant Sections without Cover Texts, or some other |
| combination of the three, merge those two alternatives to suit the |
| situation. |
| |
| If your document contains nontrivial examples of program code, we |
| recommend releasing these examples in parallel under your choice of |
| free software license, such as the GNU General Public License, to |
| permit their use in free software. |
| |
| |
| File: gcc.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top |
| |
| Contributors to GCC |
| ******************* |
| |
| The GCC project would like to thank its many contributors. Without |
| them the project would not have been nearly as successful as it has |
| been. Any omissions in this list are accidental. Feel free to contact |
| <law@redhat.com> or <gerald@pfeifer.com> if you have been left out or |
| some of your contributions are not listed. Please keep this list in |
| alphabetical order. |
| |
| * Analog Devices helped implement the support for complex data types |
| and iterators. |
| |
| * John David Anglin for threading-related fixes and improvements to |
| libstdc++-v3, and the HP-UX port. |
| |
| * James van Artsdalen wrote the code that makes efficient use of the |
| Intel 80387 register stack. |
| |
| * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta |
| Series port. |
| |
| * Alasdair Baird for various bug fixes. |
| |
| * Giovanni Bajo for analyzing lots of complicated C++ problem |
| reports. |
| |
| * Peter Barada for his work to improve code generation for new |
| ColdFire cores. |
| |
| * Gerald Baumgartner added the signature extension to the C++ front |
| end. |
| |
| * Godmar Back for his Java improvements and encouragement. |
| |
| * Scott Bambrough for help porting the Java compiler. |
| |
| * Wolfgang Bangerth for processing tons of bug reports. |
| |
| * Jon Beniston for his Microsoft Windows port of Java and port to |
| Lattice Mico32. |
| |
| * Daniel Berlin for better DWARF2 support, faster/better |
| optimizations, improved alias analysis, plus migrating GCC to |
| Bugzilla. |
| |
| * Geoff Berry for his Java object serialization work and various |
| patches. |
| |
| * Uros Bizjak for the implementation of x87 math built-in functions |
| and for various middle end and i386 back end improvements and bug |
| fixes. |
| |
| * Eric Blake for helping to make GCJ and libgcj conform to the |
| specifications. |
| |
| * Janne Blomqvist for contributions to GNU Fortran. |
| |
| * Segher Boessenkool for various fixes. |
| |
| * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and |
| other Java work. |
| |
| * Neil Booth for work on cpplib, lang hooks, debug hooks and other |
| miscellaneous clean-ups. |
| |
| * Steven Bosscher for integrating the GNU Fortran front end into GCC |
| and for contributing to the tree-ssa branch. |
| |
| * Eric Botcazou for fixing middle- and backend bugs left and right. |
| |
| * Per Bothner for his direction via the steering committee and |
| various improvements to the infrastructure for supporting new |
| languages. Chill front end implementation. Initial |
| implementations of cpplib, fix-header, config.guess, libio, and |
| past C++ library (libg++) maintainer. Dreaming up, designing and |
| implementing much of GCJ. |
| |
| * Devon Bowen helped port GCC to the Tahoe. |
| |
| * Don Bowman for mips-vxworks contributions. |
| |
| * Dave Brolley for work on cpplib and Chill. |
| |
| * Paul Brook for work on the ARM architecture and maintaining GNU |
| Fortran. |
| |
| * Robert Brown implemented the support for Encore 32000 systems. |
| |
| * Christian Bruel for improvements to local store elimination. |
| |
| * Herman A.J. ten Brugge for various fixes. |
| |
| * Joerg Brunsmann for Java compiler hacking and help with the GCJ |
| FAQ. |
| |
| * Joe Buck for his direction via the steering committee. |
| |
| * Craig Burley for leadership of the G77 Fortran effort. |
| |
| * Stephan Buys for contributing Doxygen notes for libstdc++. |
| |
| * Paolo Carlini for libstdc++ work: lots of efficiency improvements |
| to the C++ strings, streambufs and formatted I/O, hard detective |
| work on the frustrating localization issues, and keeping up with |
| the problem reports. |
| |
| * John Carr for his alias work, SPARC hacking, infrastructure |
| improvements, previous contributions to the steering committee, |
| loop optimizations, etc. |
| |
| * Stephane Carrez for 68HC11 and 68HC12 ports. |
| |
| * Steve Chamberlain for support for the Renesas SH and H8 processors |
| and the PicoJava processor, and for GCJ config fixes. |
| |
| * Glenn Chambers for help with the GCJ FAQ. |
| |
| * John-Marc Chandonia for various libgcj patches. |
| |
| * Denis Chertykov for contributing and maintaining the AVR port, the |
| first GCC port for an 8-bit architecture. |
| |
| * Scott Christley for his Objective-C contributions. |
| |
| * Eric Christopher for his Java porting help and clean-ups. |
| |
| * Branko Cibej for more warning contributions. |
| |
| * The GNU Classpath project for all of their merged runtime code. |
| |
| * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help', |
| and other random hacking. |
| |
| * Michael Cook for libstdc++ cleanup patches to reduce warnings. |
| |
| * R. Kelley Cook for making GCC buildable from a read-only directory |
| as well as other miscellaneous build process and documentation |
| clean-ups. |
| |
| * Ralf Corsepius for SH testing and minor bug fixing. |
| |
| * Stan Cox for care and feeding of the x86 port and lots of behind |
| the scenes hacking. |
| |
| * Alex Crain provided changes for the 3b1. |
| |
| * Ian Dall for major improvements to the NS32k port. |
| |
| * Paul Dale for his work to add uClinux platform support to the m68k |
| backend. |
| |
| * Dario Dariol contributed the four varieties of sample programs |
| that print a copy of their source. |
| |
| * Russell Davidson for fstream and stringstream fixes in libstdc++. |
| |
| * Bud Davis for work on the G77 and GNU Fortran compilers. |
| |
| * Mo DeJong for GCJ and libgcj bug fixes. |
| |
| * DJ Delorie for the DJGPP port, build and libiberty maintenance, |
| various bug fixes, and the M32C and MeP ports. |
| |
| * Arnaud Desitter for helping to debug GNU Fortran. |
| |
| * Gabriel Dos Reis for contributions to G++, contributions and |
| maintenance of GCC diagnostics infrastructure, libstdc++-v3, |
| including `valarray<>', `complex<>', maintaining the numerics |
| library (including that pesky `<limits>' :-) and keeping |
| up-to-date anything to do with numbers. |
| |
| * Ulrich Drepper for his work on glibc, testing of GCC using glibc, |
| ISO C99 support, CFG dumping support, etc., plus support of the |
| C++ runtime libraries including for all kinds of C interface |
| issues, contributing and maintaining `complex<>', sanity checking |
| and disbursement, configuration architecture, libio maintenance, |
| and early math work. |
| |
| * Zdenek Dvorak for a new loop unroller and various fixes. |
| |
| * Michael Eager for his work on the Xilinx MicroBlaze port. |
| |
| * Richard Earnshaw for his ongoing work with the ARM. |
| |
| * David Edelsohn for his direction via the steering committee, |
| ongoing work with the RS6000/PowerPC port, help cleaning up Haifa |
| loop changes, doing the entire AIX port of libstdc++ with his bare |
| hands, and for ensuring GCC properly keeps working on AIX. |
| |
| * Kevin Ediger for the floating point formatting of num_put::do_put |
| in libstdc++. |
| |
| * Phil Edwards for libstdc++ work including configuration hackery, |
| documentation maintainer, chief breaker of the web pages, the |
| occasional iostream bug fix, and work on shared library symbol |
| versioning. |
| |
| * Paul Eggert for random hacking all over GCC. |
| |
| * Mark Elbrecht for various DJGPP improvements, and for libstdc++ |
| configuration support for locales and fstream-related fixes. |
| |
| * Vadim Egorov for libstdc++ fixes in strings, streambufs, and |
| iostreams. |
| |
| * Christian Ehrhardt for dealing with bug reports. |
| |
| * Ben Elliston for his work to move the Objective-C runtime into its |
| own subdirectory and for his work on autoconf. |
| |
| * Revital Eres for work on the PowerPC 750CL port. |
| |
| * Marc Espie for OpenBSD support. |
| |
| * Doug Evans for much of the global optimization framework, arc, |
| m32r, and SPARC work. |
| |
| * Christopher Faylor for his work on the Cygwin port and for caring |
| and feeding the gcc.gnu.org box and saving its users tons of spam. |
| |
| * Fred Fish for BeOS support and Ada fixes. |
| |
| * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. |
| |
| * Peter Gerwinski for various bug fixes and the Pascal front end. |
| |
| * Kaveh R. Ghazi for his direction via the steering committee, |
| amazing work to make `-W -Wall -W* -Werror' useful, and |
| 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, the moxie port, and |
| Java front end work. |
| |
| * Stu Grossman for gdb hacking, allowing GCJ developers to debug |
| Java code. |
| |
| * Michael K. Gschwind contributed the port to the PDP-11. |
| |
| * Richard Guenther for his ongoing middle-end contributions and bug |
| fixes and for release management. |
| |
| * Ron Guilmette implemented the `protoize' and `unprotoize' tools, |
| the support for Dwarf symbolic debugging information, and much of |
| the support for System V Release 4. He has also worked heavily on |
| the Intel 386 and 860 support. |
| |
| * 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, and maintaining the |
| IRIX, Solaris 2, and Tru64 UNIX ports. |
| |
| * Hartmut Penner for work on the s390 port. |
| |
| * Paul Petersen wrote the machine description for the Alliant FX/8. |
| |
| * Alexandre Petit-Bianco for implementing much of the Java compiler |
| and continued Java maintainership. |
| |
| * Matthias Pfaller for major improvements to the NS32k port. |
| |
| * Gerald Pfeifer for his direction via the steering committee, |
| pointing out lots of problems we need to solve, maintenance of the |
| web pages, and taking care of documentation maintenance in general. |
| |
| * Andrew Pinski for processing bug reports by the dozen. |
| |
| * Ovidiu Predescu for his work on the Objective-C front end and |
| runtime libraries. |
| |
| * Jerry Quinn for major performance improvements in C++ formatted |
| I/O. |
| |
| * Ken Raeburn for various improvements to checker, MIPS ports and |
| various cleanups in the compiler. |
| |
| * Rolf W. Rasmussen for hacking on AWT. |
| |
| * David Reese of Sun Microsystems contributed to the Solaris on |
| PowerPC port. |
| |
| * Volker Reichelt for keeping up with the problem reports. |
| |
| * Joern Rennecke for maintaining the sh port, loop, regmove & reload |
| hacking. |
| |
| * 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. |
| |
| * Dodji Seketeli for numerous C++ bug fixes and debug info |
| improvements. |
| |
| * 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 the Go frontend, the initial mips16 and mips64 |
| support, general configury hacking, fixincludes, etc. |
| |
| * Holger Teutsch provided the support for the Clipper CPU. |
| |
| * Gary Thomas for his ongoing work to make the PPC work for |
| GNU/Linux. |
| |
| * Philipp Thomas for random bug fixes throughout the compiler |
| |
| * Jason Thorpe for thread support in libstdc++ on NetBSD. |
| |
| * Kresten Krab Thorup wrote the run time support for the Objective-C |
| language and the fantastic Java bytecode interpreter. |
| |
| * Michael Tiemann for random bug fixes, the first instruction |
| scheduler, initial C++ support, function integration, NS32k, SPARC |
| and M88k machine description work, delay slot scheduling. |
| |
| * Andreas Tobler for his work porting libgcj to Darwin. |
| |
| * Teemu Torma for thread safe exception handling support. |
| |
| * Leonard Tower wrote parts of the parser, RTL generator, and RTL |
| definitions, and of the VAX machine description. |
| |
| * Daniel Towner and Hariharan Sandanagobalane contributed and |
| maintain the picoChip port. |
| |
| * Tom Tromey for internationalization support and for his many Java |
| contributions and libgcj maintainership. |
| |
| * Lassi Tuura for improvements to config.guess to determine HP |
| processor types. |
| |
| * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. |
| |
| * Andy Vaught for the design and initial implementation of the GNU |
| Fortran front end. |
| |
| * Brent Verner for work with the libstdc++ cshadow files and their |
| associated configure steps. |
| |
| * Todd Vierling for contributions for NetBSD ports. |
| |
| * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML |
| guidance. |
| |
| * Dean Wakerley for converting the install documentation from HTML |
| to texinfo in time for GCC 3.0. |
| |
| * Krister Walfridsson for random bug fixes. |
| |
| * Feng Wang for contributions to GNU Fortran. |
| |
| * Stephen M. Webb for time and effort on making libstdc++ shadow |
| files work with the tricky Solaris 8+ headers, and for pushing the |
| build-time header tree. |
| |
| * 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. |
| |
| |
| 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. |
| |
| [index] |
| * Menu: |
| |
| * ###: Overall Options. (line 209) |
| * -fno-keep-inline-dllexport: Optimize Options. (line 305) |
| * -fprofile-generate-sampling: Optimize Options. (line 1773) |
| * -mcpu: RX Options. (line 30) |
| * -Wno-thread-attr-bind-param: Warning Options. (line 606) |
| * -Wno-thread-mismatched-lock-acq-rel: Warning Options. (line 594) |
| * -Wno-thread-mismatched-lock-order: Warning Options. (line 589) |
| * -Wno-thread-reentrant-lock: Warning Options. (line 598) |
| * -Wno-thread-unguarded-func: Warning Options. (line 584) |
| * -Wno-thread-unguarded-var: Warning Options. (line 579) |
| * -Wno-thread-unsupported-lock-name: Warning Options. (line 602) |
| * -Wthread-attr-bind-param: Warning Options. (line 606) |
| * -Wthread-mismatched-lock-acq-rel: Warning Options. (line 594) |
| * -Wthread-mismatched-lock-order: Warning Options. (line 589) |
| * -Wthread-reentrant-lock: Warning Options. (line 598) |
| * -Wthread-unguarded-func: Warning Options. (line 584) |
| * -Wthread-unguarded-var: Warning Options. (line 579) |
| * -Wthread-unsupported-lock-name: Warning Options. (line 602) |
| * 8bit-idiv: i386 and x86-64 Options. |
| (line 680) |
| * A: Preprocessor Options. |
| (line 551) |
| * 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 154) |
| * avx256-split-unaligned-load: i386 and x86-64 Options. |
| (line 689) |
| * avx256-split-unaligned-store: i386 and x86-64 Options. |
| (line 689) |
| * B: Directory Options. (line 46) |
| * 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 609) |
| * c: Overall Options. (line 164) |
| * canonical-prefixes: Overall Options. (line 338) |
| * client_name: Darwin Options. (line 199) |
| * compatibility_version: Darwin Options. (line 199) |
| * coverage: Debugging Options. (line 371) |
| * current_version: Darwin Options. (line 199) |
| * D: Preprocessor Options. |
| (line 34) |
| * d: Debugging Options. (line 497) |
| * dA: Debugging Options. (line 704) |
| * dD <1>: Preprocessor Options. |
| (line 583) |
| * dD: Debugging Options. (line 708) |
| * dead_strip: Darwin Options. (line 199) |
| * dependency-file: Darwin Options. (line 199) |
| * dH: Debugging Options. (line 712) |
| * dI: Preprocessor Options. |
| (line 592) |
| * dM: Preprocessor Options. |
| (line 567) |
| * dm: Debugging Options. (line 715) |
| * dN: Preprocessor Options. |
| (line 589) |
| * dP: Debugging Options. (line 724) |
| * dp: Debugging Options. (line 719) |
| * dU: Preprocessor Options. |
| (line 596) |
| * dumpmachine: Debugging Options. (line 1203) |
| * dumpspecs: Debugging Options. (line 1211) |
| * dumpversion: Debugging Options. (line 1207) |
| * dv: Debugging Options. (line 728) |
| * dx: Debugging Options. (line 733) |
| * 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 185) |
| * 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 1394) |
| * falign-jumps: Optimize Options. (line 1444) |
| * falign-labels: Optimize Options. (line 1412) |
| * falign-loops: Optimize Options. (line 1430) |
| * fassociative-math: Optimize Options. (line 1965) |
| * fasynchronous-unwind-tables: Code Gen Options. (line 64) |
| * fauto-inc-dec: Optimize Options. (line 510) |
| * fbounds-check: Code Gen Options. (line 15) |
| * fbranch-probabilities: Optimize Options. (line 2098) |
| * fbranch-target-load-optimize: Optimize Options. (line 2209) |
| * fbranch-target-load-optimize2: Optimize Options. (line 2215) |
| * fbtr-bb-exclusive: Optimize Options. (line 2219) |
| * fcall-saved: Code Gen Options. (line 262) |
| * fcall-used: Code Gen Options. (line 248) |
| * fcaller-saves: Optimize Options. (line 779) |
| * fcallgraph-profiles-sections: Optimize Options. (line 1863) |
| * fcheck-data-deps: Optimize Options. (line 1052) |
| * fcheck-new: C++ Dialect Options. |
| (line 45) |
| * fcombine-stack-adjustments: Optimize Options. (line 792) |
| * fcommon: Variable Attributes. |
| (line 105) |
| * fcompare-debug: Debugging Options. (line 160) |
| * fcompare-debug-second: Debugging Options. (line 186) |
| * fcompare-elim: Optimize Options. (line 1714) |
| * fcond-mismatch: C Dialect Options. (line 290) |
| * fconserve-space: C++ Dialect Options. |
| (line 55) |
| * fconserve-stack: Optimize Options. (line 798) |
| * fconstant-string-class: Objective-C and Objective-C++ Dialect Options. |
| (line 30) |
| * fconstexpr-depth: C++ Dialect Options. |
| (line 67) |
| * fcprop-registers: Optimize Options. (line 1736) |
| * fcrossjumping: Optimize Options. (line 503) |
| * fcse-follow-jumps: Optimize Options. (line 431) |
| * fcse-skip-blocks: Optimize Options. (line 440) |
| * fcx-fortran-rules: Optimize Options. (line 2079) |
| * fcx-limited-range: Optimize Options. (line 2067) |
| * fdata-sections: Optimize Options. (line 2190) |
| * fdbg-cnt: Debugging Options. (line 424) |
| * fdbg-cnt-list: Debugging Options. (line 421) |
| * fdce: Optimize Options. (line 516) |
| * fdebug-prefix-map: Debugging Options. (line 287) |
| * fdelayed-branch: Optimize Options. (line 628) |
| * fdelete-null-pointer-checks: Optimize Options. (line 539) |
| * fdevirtualize: Optimize Options. (line 557) |
| * fdiagnostics-show-location: Language Independent Options. |
| (line 21) |
| * fdiagnostics-show-option: Language Independent Options. |
| (line 36) |
| * fdirectives-only: Preprocessor Options. |
| (line 459) |
| * fdisable-: Debugging Options. (line 434) |
| * fdollars-in-identifiers <1>: Interoperation. (line 146) |
| * fdollars-in-identifiers: Preprocessor Options. |
| (line 481) |
| * fdse: Optimize Options. (line 520) |
| * fdump-class-hierarchy: Debugging Options. (line 764) |
| * fdump-final-insns: Debugging Options. (line 154) |
| * fdump-ipa: Debugging Options. (line 772) |
| * fdump-noaddr: Debugging Options. (line 737) |
| * fdump-passes: Debugging Options. (line 790) |
| * fdump-rtl-alignments: Debugging Options. (line 516) |
| * fdump-rtl-all: Debugging Options. (line 701) |
| * fdump-rtl-asmcons: Debugging Options. (line 519) |
| * fdump-rtl-auto_inc_dec: Debugging Options. (line 523) |
| * fdump-rtl-barriers: Debugging Options. (line 527) |
| * fdump-rtl-bbpart: Debugging Options. (line 530) |
| * fdump-rtl-bbro: Debugging Options. (line 533) |
| * fdump-rtl-btl2: Debugging Options. (line 537) |
| * fdump-rtl-bypass: Debugging Options. (line 541) |
| * fdump-rtl-ce1: Debugging Options. (line 552) |
| * fdump-rtl-ce2: Debugging Options. (line 552) |
| * fdump-rtl-ce3: Debugging Options. (line 552) |
| * fdump-rtl-combine: Debugging Options. (line 544) |
| * fdump-rtl-compgotos: Debugging Options. (line 547) |
| * fdump-rtl-cprop_hardreg: Debugging Options. (line 556) |
| * fdump-rtl-csa: Debugging Options. (line 559) |
| * fdump-rtl-cse1: Debugging Options. (line 563) |
| * fdump-rtl-cse2: Debugging Options. (line 563) |
| * fdump-rtl-dbr: Debugging Options. (line 570) |
| * fdump-rtl-dce: Debugging Options. (line 567) |
| * fdump-rtl-dce1: Debugging Options. (line 574) |
| * fdump-rtl-dce2: Debugging Options. (line 574) |
| * fdump-rtl-dfinish: Debugging Options. (line 698) |
| * fdump-rtl-dfinit: Debugging Options. (line 698) |
| * fdump-rtl-eh: Debugging Options. (line 578) |
| * fdump-rtl-eh_ranges: Debugging Options. (line 581) |
| * fdump-rtl-expand: Debugging Options. (line 584) |
| * fdump-rtl-fwprop1: Debugging Options. (line 588) |
| * fdump-rtl-fwprop2: Debugging Options. (line 588) |
| * fdump-rtl-gcse1: Debugging Options. (line 593) |
| * fdump-rtl-gcse2: Debugging Options. (line 593) |
| * fdump-rtl-init-regs: Debugging Options. (line 597) |
| * fdump-rtl-initvals: Debugging Options. (line 600) |
| * fdump-rtl-into_cfglayout: Debugging Options. (line 603) |
| * fdump-rtl-ira: Debugging Options. (line 606) |
| * fdump-rtl-jump: Debugging Options. (line 609) |
| * fdump-rtl-loop2: Debugging Options. (line 612) |
| * fdump-rtl-mach: Debugging Options. (line 616) |
| * fdump-rtl-mode_sw: Debugging Options. (line 620) |
| * fdump-rtl-outof_cfglayout: Debugging Options. (line 626) |
| * fdump-rtl-peephole2: Debugging Options. (line 629) |
| * fdump-rtl-postreload: Debugging Options. (line 632) |
| * fdump-rtl-pro_and_epilogue: Debugging Options. (line 635) |
| * fdump-rtl-regclass: Debugging Options. (line 698) |
| * fdump-rtl-regmove: Debugging Options. (line 638) |
| * fdump-rtl-rnreg: Debugging Options. (line 623) |
| * fdump-rtl-sched1: Debugging Options. (line 642) |
| * fdump-rtl-sched2: Debugging Options. (line 642) |
| * fdump-rtl-see: Debugging Options. (line 646) |
| * fdump-rtl-seqabstr: Debugging Options. (line 649) |
| * fdump-rtl-shorten: Debugging Options. (line 652) |
| * fdump-rtl-sibling: Debugging Options. (line 655) |
| * fdump-rtl-sms: Debugging Options. (line 668) |
| * fdump-rtl-split1: Debugging Options. (line 662) |
| * fdump-rtl-split2: Debugging Options. (line 662) |
| * fdump-rtl-split3: Debugging Options. (line 662) |
| * fdump-rtl-split4: Debugging Options. (line 662) |
| * fdump-rtl-split5: Debugging Options. (line 662) |
| * fdump-rtl-stack: Debugging Options. (line 672) |
| * fdump-rtl-subreg1: Debugging Options. (line 678) |
| * fdump-rtl-subreg2: Debugging Options. (line 678) |
| * fdump-rtl-subregs_of_mode_finish: Debugging Options. (line 698) |
| * fdump-rtl-subregs_of_mode_init: Debugging Options. (line 698) |
| * fdump-rtl-unshare: Debugging Options. (line 682) |
| * fdump-rtl-vartrack: Debugging Options. (line 685) |
| * fdump-rtl-vregs: Debugging Options. (line 688) |
| * fdump-rtl-web: Debugging Options. (line 691) |
| * fdump-statistics: Debugging Options. (line 794) |
| * fdump-translation-unit: Debugging Options. (line 755) |
| * fdump-tree: Debugging Options. (line 805) |
| * fdump-tree-alias: Debugging Options. (line 899) |
| * fdump-tree-all: Debugging Options. (line 989) |
| * fdump-tree-ccp: Debugging Options. (line 903) |
| * fdump-tree-cfg: Debugging Options. (line 879) |
| * fdump-tree-ch: Debugging Options. (line 891) |
| * fdump-tree-copyprop: Debugging Options. (line 919) |
| * fdump-tree-copyrename: Debugging Options. (line 965) |
| * fdump-tree-dce: Debugging Options. (line 927) |
| * fdump-tree-dom: Debugging Options. (line 945) |
| * fdump-tree-dse: Debugging Options. (line 950) |
| * fdump-tree-forwprop: Debugging Options. (line 960) |
| * fdump-tree-fre: Debugging Options. (line 915) |
| * fdump-tree-gimple: Debugging Options. (line 874) |
| * fdump-tree-mudflap: Debugging Options. (line 931) |
| * fdump-tree-nrv: Debugging Options. (line 970) |
| * fdump-tree-optimized: Debugging Options. (line 871) |
| * fdump-tree-original: Debugging Options. (line 868) |
| * fdump-tree-phiopt: Debugging Options. (line 955) |
| * fdump-tree-pre: Debugging Options. (line 911) |
| * fdump-tree-sink: Debugging Options. (line 941) |
| * fdump-tree-slp: Debugging Options. (line 980) |
| * fdump-tree-sra: Debugging Options. (line 936) |
| * fdump-tree-ssa: Debugging Options. (line 895) |
| * fdump-tree-store_copyprop: Debugging Options. (line 923) |
| * fdump-tree-storeccp: Debugging Options. (line 907) |
| * fdump-tree-vcg: Debugging Options. (line 883) |
| * fdump-tree-vect: Debugging Options. (line 975) |
| * fdump-tree-vrp: Debugging Options. (line 985) |
| * fdump-unnumbered: Debugging Options. (line 743) |
| * fdump-unnumbered-links: Debugging Options. (line 749) |
| * fdwarf2-cfi-asm: Debugging Options. (line 291) |
| * fearly-inlining: Optimize Options. (line 262) |
| * feliminate-dwarf2-dups: Debugging Options. (line 199) |
| * feliminate-unused-debug-symbols: Debugging Options. (line 52) |
| * feliminate-unused-debug-types: Debugging Options. (line 1215) |
| * fenable-: Debugging Options. (line 434) |
| * fenable-icf-debug: Debugging Options. (line 274) |
| * fexceptions: Code Gen Options. (line 34) |
| * fexcess-precision: Optimize Options. (line 1893) |
| * fexec-charset: Preprocessor Options. |
| (line 508) |
| * fexpensive-optimizations: Optimize Options. (line 564) |
| * fextended-identifiers: Preprocessor Options. |
| (line 484) |
| * ffast-math: Optimize Options. (line 1916) |
| * ffinite-math-only: Optimize Options. (line 1991) |
| * ffix-and-continue: Darwin Options. (line 106) |
| * ffixed: Code Gen Options. (line 236) |
| * ffloat-store <1>: Disappointments. (line 77) |
| * ffloat-store: Optimize Options. (line 1879) |
| * ffor-scope: C++ Dialect Options. |
| (line 121) |
| * fforward-propagate: Optimize Options. (line 174) |
| * ffp-contract: Optimize Options. (line 183) |
| * ffreestanding <1>: Function Attributes. |
| (line 459) |
| * ffreestanding <2>: Warning Options. (line 240) |
| * ffreestanding <3>: C Dialect Options. (line 225) |
| * ffreestanding: Standards. (line 88) |
| * ffriend-injection: C++ Dialect Options. |
| (line 91) |
| * ffunction-sections: Optimize Options. (line 2190) |
| * fgcse: Optimize Options. (line 454) |
| * fgcse-after-reload: Optimize Options. (line 490) |
| * fgcse-las: Optimize Options. (line 483) |
| * fgcse-lm: Optimize Options. (line 465) |
| * fgcse-sm: Optimize Options. (line 474) |
| * fgnu-runtime: Objective-C and Objective-C++ Dialect Options. |
| (line 39) |
| * fgnu89-inline: C Dialect Options. (line 133) |
| * fgraphite-identity: Optimize Options. (line 1033) |
| * fhosted: C Dialect Options. (line 218) |
| * fif-conversion: Optimize Options. (line 524) |
| * fif-conversion2: Optimize Options. (line 533) |
| * filelist: Darwin Options. (line 199) |
| * findirect-data: Darwin Options. (line 106) |
| * findirect-inlining: Optimize Options. (line 235) |
| * finhibit-size-directive: Code Gen Options. (line 158) |
| * finline-functions: Optimize Options. (line 243) |
| * finline-functions-called-once: Optimize Options. (line 254) |
| * finline-limit: Optimize Options. (line 279) |
| * finline-small-functions: Optimize Options. (line 227) |
| * finput-charset: Preprocessor Options. |
| (line 521) |
| * finstrument-functions <1>: Function Attributes. |
| (line 899) |
| * 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 349) |
| * fipa-cp: Optimize Options. (line 868) |
| * fipa-cp-clone: Optimize Options. (line 876) |
| * fipa-matrix-reorg: Optimize Options. (line 886) |
| * fipa-profile: Optimize Options. (line 860) |
| * fipa-pta: Optimize Options. (line 854) |
| * fipa-pure-const: Optimize Options. (line 832) |
| * fipa-reference: Optimize Options. (line 836) |
| * fipa-sra: Optimize Options. (line 272) |
| * fipa-struct-reorg: Optimize Options. (line 840) |
| * fira-loop-pressure: Optimize Options. (line 603) |
| * fira-verbose: Optimize Options. (line 623) |
| * fivopts: Optimize Options. (line 1128) |
| * fkeep-inline-functions <1>: Inline. (line 51) |
| * fkeep-inline-functions: Optimize Options. (line 311) |
| * fkeep-static-consts: Optimize Options. (line 318) |
| * flat_namespace: Darwin Options. (line 199) |
| * flax-vector-conversions: C Dialect Options. (line 295) |
| * fleading-underscore: Code Gen Options. (line 432) |
| * floop-block: Optimize Options. (line 1004) |
| * floop-flatten: Optimize Options. (line 1041) |
| * floop-interchange: Optimize Options. (line 957) |
| * floop-parallelize-all: Optimize Options. (line 1046) |
| * floop-strip-mine: Optimize Options. (line 982) |
| * flto: Optimize Options. (line 1508) |
| * flto-partition: Optimize Options. (line 1672) |
| * fmax-errors: Warning Options. (line 18) |
| * fmem-report: Debugging Options. (line 315) |
| * fmerge-all-constants: Optimize Options. (line 337) |
| * fmerge-constants: Optimize Options. (line 327) |
| * fmerge-debug-strings: Debugging Options. (line 279) |
| * fmessage-length: Language Independent Options. |
| (line 15) |
| * fmodulo-sched: Optimize Options. (line 348) |
| * fmodulo-sched-allow-regmoves: Optimize Options. (line 353) |
| * fmove-loop-invariants: Optimize Options. (line 2180) |
| * fms-extensions <1>: Unnamed Fields. (line 36) |
| * fms-extensions <2>: C++ Dialect Options. |
| (line 156) |
| * fms-extensions: C Dialect Options. (line 243) |
| * fmudflap: Optimize Options. (line 393) |
| * fmudflapir: Optimize Options. (line 393) |
| * fmudflapth: Optimize Options. (line 393) |
| * fnext-runtime: Objective-C and Objective-C++ Dialect Options. |
| (line 43) |
| * fno-access-control: C++ Dialect Options. |
| (line 41) |
| * fno-asm: C Dialect Options. (line 170) |
| * fno-branch-count-reg: Optimize Options. (line 360) |
| * fno-builtin <1>: Other Builtins. (line 14) |
| * fno-builtin <2>: Function Attributes. |
| (line 459) |
| * fno-builtin <3>: Warning Options. (line 240) |
| * fno-builtin: C Dialect Options. (line 184) |
| * fno-common <1>: Variable Attributes. |
| (line 105) |
| * fno-common: Code Gen Options. (line 135) |
| * fno-compare-debug: Debugging Options. (line 160) |
| * fno-deduce-init-list: C++ Dialect Options. |
| (line 73) |
| * fno-default-inline <1>: Inline. (line 71) |
| * fno-default-inline <2>: Optimize Options. (line 159) |
| * fno-default-inline: C++ Dialect Options. |
| (line 330) |
| * fno-defer-pop: Optimize Options. (line 166) |
| * fno-diagnostics-show-option: Language Independent Options. |
| (line 36) |
| * fno-dwarf2-cfi-asm: Debugging Options. (line 291) |
| * fno-elide-constructors: C++ Dialect Options. |
| (line 104) |
| * fno-enforce-eh-specs: C++ Dialect Options. |
| (line 110) |
| * fno-for-scope: C++ Dialect Options. |
| (line 121) |
| * fno-function-cse: Optimize Options. (line 370) |
| * fno-gnu-keywords: C++ Dialect Options. |
| (line 133) |
| * fno-guess-branch-probability: Optimize Options. (line 1266) |
| * fno-ident: Code Gen Options. (line 155) |
| * fno-implement-inlines <1>: C++ Interface. (line 75) |
| * fno-implement-inlines: C++ Dialect Options. |
| (line 150) |
| * fno-implicit-inline-templates: C++ Dialect Options. |
| (line 144) |
| * fno-implicit-templates <1>: Template Instantiation. |
| (line 87) |
| * fno-implicit-templates: C++ Dialect Options. |
| (line 138) |
| * fno-inline: Optimize Options. (line 221) |
| * fno-ira-share-save-slots: Optimize Options. (line 611) |
| * fno-ira-share-spill-slots: Optimize Options. (line 617) |
| * fno-jump-tables: Code Gen Options. (line 228) |
| * fno-math-errno: Optimize Options. (line 1930) |
| * fno-merge-debug-strings: Debugging Options. (line 279) |
| * fno-nil-receivers: Objective-C and Objective-C++ Dialect Options. |
| (line 49) |
| * fno-nonansi-builtins: C++ Dialect Options. |
| (line 161) |
| * fno-operator-names: C++ Dialect Options. |
| (line 177) |
| * fno-optional-diags: C++ Dialect Options. |
| (line 181) |
| * fno-peephole: Optimize Options. (line 1257) |
| * fno-peephole2: Optimize Options. (line 1257) |
| * fno-pretty-templates: C++ Dialect Options. |
| (line 191) |
| * fno-rtti: C++ Dialect Options. |
| (line 209) |
| * fno-sched-interblock: Optimize Options. (line 654) |
| * fno-sched-spec: Optimize Options. (line 659) |
| * fno-set-stack-executable: i386 and x86-64 Windows Options. |
| (line 46) |
| * fno-show-column: Preprocessor Options. |
| (line 546) |
| * fno-signed-bitfields: C Dialect Options. (line 328) |
| * fno-signed-zeros: Optimize Options. (line 2003) |
| * fno-stack-limit: Code Gen Options. (line 400) |
| * fno-threadsafe-statics: C++ Dialect Options. |
| (line 240) |
| * fno-toplevel-reorder: Optimize Options. (line 1464) |
| * fno-trapping-math: Optimize Options. (line 2013) |
| * fno-unsigned-bitfields: C Dialect Options. (line 328) |
| * fno-use-cxa-get-exception-ptr: C++ Dialect Options. |
| (line 253) |
| * fno-var-tracking-assignments: Debugging Options. (line 1126) |
| * fno-var-tracking-assignments-toggle: Debugging Options. (line 1136) |
| * fno-weak: C++ Dialect Options. |
| (line 315) |
| * fno-working-directory: Preprocessor Options. |
| (line 531) |
| * fno-zero-initialized-in-bss: Optimize Options. (line 381) |
| * fnon-call-exceptions: Code Gen Options. (line 48) |
| * fnothrow-opt: C++ Dialect Options. |
| (line 166) |
| * fobjc-abi-version: Objective-C and Objective-C++ Dialect Options. |
| (line 56) |
| * fobjc-call-cxx-cdtors: Objective-C and Objective-C++ Dialect Options. |
| (line 67) |
| * fobjc-direct-dispatch: Objective-C and Objective-C++ Dialect Options. |
| (line 92) |
| * fobjc-exceptions: Objective-C and Objective-C++ Dialect Options. |
| (line 96) |
| * fobjc-gc: Objective-C and Objective-C++ Dialect Options. |
| (line 105) |
| * fobjc-nilcheck: Objective-C and Objective-C++ Dialect Options. |
| (line 111) |
| * fobjc-std: Objective-C and Objective-C++ Dialect Options. |
| (line 120) |
| * fomit-frame-pointer: Optimize Options. (line 194) |
| * fopenmp: C Dialect Options. (line 235) |
| * foptimize-register-move: Optimize Options. (line 571) |
| * foptimize-sibling-calls: Optimize Options. (line 216) |
| * force_cpusubtype_ALL: Darwin Options. (line 138) |
| * force_flat_namespace: Darwin Options. (line 199) |
| * fpack-struct: Code Gen Options. (line 279) |
| * fpartial-inlining: Optimize Options. (line 1232) |
| * 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 2172) |
| * fpermissive: C++ Dialect Options. |
| (line 186) |
| * fPIC: Code Gen Options. (line 205) |
| * fpic: Code Gen Options. (line 184) |
| * fPIE: Code Gen Options. (line 218) |
| * fpie: Code Gen Options. (line 218) |
| * fplan9-extensions: Unnamed Fields. (line 44) |
| * fpmu-profile-generate: Optimize Options. (line 1801) |
| * fpmu-profile-use: Optimize Options. (line 1812) |
| * fpost-ipa-mem-report: Debugging Options. (line 321) |
| * fpre-ipa-mem-report: Debugging Options. (line 319) |
| * fpredictive-commoning: Optimize Options. (line 1239) |
| * fprefetch-loop-arrays: Optimize Options. (line 1246) |
| * fpreprocessed: Preprocessor Options. |
| (line 489) |
| * fprofile-arcs <1>: Other Builtins. (line 247) |
| * fprofile-arcs: Debugging Options. (line 356) |
| * fprofile-correction: Optimize Options. (line 1743) |
| * fprofile-dir: Optimize Options. (line 1750) |
| * fprofile-generate: Optimize Options. (line 1761) |
| * fprofile-use: Optimize Options. (line 1786) |
| * fprofile-values: Optimize Options. (line 2121) |
| * fpu: RX Options. (line 17) |
| * frandom-seed: Debugging Options. (line 1020) |
| * freciprocal-math: Optimize Options. (line 1982) |
| * frecord-gcc-switches: Code Gen Options. (line 174) |
| * frecord-gcc-switches-in-elf: Optimize Options. (line 1871) |
| * freg-struct-return: Code Gen Options. (line 88) |
| * fregmove: Optimize Options. (line 571) |
| * frename-registers: Optimize Options. (line 2139) |
| * freorder-blocks: Optimize Options. (line 1283) |
| * freorder-blocks-and-partition: Optimize Options. (line 1289) |
| * freorder-functions: Optimize Options. (line 1300) |
| * freplace-objc-classes: Objective-C and Objective-C++ Dialect Options. |
| (line 131) |
| * frepo <1>: Template Instantiation. |
| (line 62) |
| * frepo: C++ Dialect Options. |
| (line 204) |
| * frerun-cse-after-loop: Optimize Options. (line 448) |
| * freschedule-modulo-scheduled-loops: Optimize Options. (line 755) |
| * fripa: Optimize Options. (line 1817) |
| * fripa-disallow-asm-modules: Optimize Options. (line 1825) |
| * fripa-disallow-opt-mismatch: Optimize Options. (line 1833) |
| * fripa-no-promote-always-inline-func: Optimize Options. (line 1840) |
| * fripa-peel-size-limit: Optimize Options. (line 1849) |
| * fripa-unroll-size-limit: Optimize Options. (line 1856) |
| * fripa-verbose: Optimize Options. (line 1844) |
| * frounding-math: Optimize Options. (line 2028) |
| * fsched-critical-path-heuristic: Optimize Options. (line 721) |
| * fsched-dep-count-heuristic: Optimize Options. (line 748) |
| * fsched-group-heuristic: Optimize Options. (line 715) |
| * fsched-last-insn-heuristic: Optimize Options. (line 741) |
| * fsched-pressure: Optimize Options. (line 664) |
| * fsched-rank-heuristic: Optimize Options. (line 734) |
| * fsched-spec-insn-heuristic: Optimize Options. (line 727) |
| * fsched-spec-load: Optimize Options. (line 673) |
| * fsched-spec-load-dangerous: Optimize Options. (line 678) |
| * fsched-stalled-insns: Optimize Options. (line 684) |
| * fsched-stalled-insns-dep: Optimize Options. (line 694) |
| * fsched-verbose: Debugging Options. (line 1030) |
| * fsched2-use-superblocks: Optimize Options. (line 704) |
| * fschedule-insns: Optimize Options. (line 635) |
| * fschedule-insns2: Optimize Options. (line 645) |
| * fsection-anchors: Optimize Options. (line 2240) |
| * fsel-sched-pipelining: Optimize Options. (line 769) |
| * fsel-sched-pipelining-outer-loops: Optimize Options. (line 774) |
| * fselective-scheduling: Optimize Options. (line 761) |
| * fselective-scheduling2: Optimize Options. (line 765) |
| * 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 2048) |
| * fsigned-bitfields <1>: Non-bugs. (line 57) |
| * fsigned-bitfields: C Dialect Options. (line 328) |
| * fsigned-char <1>: Characters implementation. |
| (line 31) |
| * fsigned-char: C Dialect Options. (line 318) |
| * fsingle-precision-constant: Optimize Options. (line 2063) |
| * fsplit-ivs-in-unroller: Optimize Options. (line 1213) |
| * fsplit-stack <1>: Function Attributes. |
| (line 904) |
| * fsplit-stack: Code Gen Options. (line 414) |
| * fsplit-wide-types: Optimize Options. (line 423) |
| * fstack-check: Code Gen Options. (line 361) |
| * fstack-limit-register: Code Gen Options. (line 400) |
| * fstack-limit-symbol: Code Gen Options. (line 400) |
| * fstack-protector: Optimize Options. (line 2223) |
| * fstack-protector-all: Optimize Options. (line 2232) |
| * fstack-protector-strong: Optimize Options. (line 2235) |
| * fstack-usage: Debugging Options. (line 325) |
| * fstats: C++ Dialect Options. |
| (line 219) |
| * fstrict-aliasing: Optimize Options. (line 1313) |
| * fstrict-enums: C++ Dialect Options. |
| (line 224) |
| * fstrict-overflow: Optimize Options. (line 1359) |
| * fstrict-volatile-bitfields: Code Gen Options. (line 517) |
| * fsyntax-only: Warning Options. (line 14) |
| * ftabstop: Preprocessor Options. |
| (line 502) |
| * ftemplate-depth: C++ Dialect Options. |
| (line 233) |
| * ftest-coverage: Debugging Options. (line 412) |
| * fthread-jumps: Optimize Options. (line 414) |
| * ftime-report: Debugging Options. (line 311) |
| * ftls-model: Code Gen Options. (line 443) |
| * ftracer: Optimize Options. (line 1196) |
| * ftrapv: Code Gen Options. (line 22) |
| * ftree-bit-ccp: Optimize Options. (line 900) |
| * ftree-builtin-call-dce: Optimize Options. (line 920) |
| * ftree-ccp: Optimize Options. (line 906) |
| * ftree-ch: Optimize Options. (line 940) |
| * ftree-copy-prop: Optimize Options. (line 827) |
| * ftree-copyrename: Optimize Options. (line 1152) |
| * ftree-dce: Optimize Options. (line 916) |
| * ftree-dominator-opts: Optimize Options. (line 926) |
| * ftree-dse: Optimize Options. (line 933) |
| * ftree-forwprop: Optimize Options. (line 812) |
| * ftree-fre: Optimize Options. (line 816) |
| * ftree-loop-im: Optimize Options. (line 1113) |
| * ftree-loop-ivcanon: Optimize Options. (line 1122) |
| * ftree-loop-linear: Optimize Options. (line 951) |
| * ftree-loop-optimize: Optimize Options. (line 947) |
| * ftree-parallelize-loops: Optimize Options. (line 1133) |
| * ftree-phiprop: Optimize Options. (line 823) |
| * ftree-pre: Optimize Options. (line 808) |
| * ftree-pta: Optimize Options. (line 1142) |
| * ftree-reassoc: Optimize Options. (line 804) |
| * ftree-sink: Optimize Options. (line 896) |
| * ftree-slp-vectorize: Optimize Options. (line 1171) |
| * ftree-sra: Optimize Options. (line 1146) |
| * ftree-ter: Optimize Options. (line 1159) |
| * ftree-vect-loop-version: Optimize Options. (line 1175) |
| * ftree-vectorize: Optimize Options. (line 1167) |
| * ftree-vectorizer-verbose: Debugging Options. (line 993) |
| * ftree-vrp: Optimize Options. (line 1187) |
| * funit-at-a-time: Optimize Options. (line 1457) |
| * funroll-all-loops: Optimize Options. (line 1207) |
| * funroll-loops: Optimize Options. (line 1201) |
| * funsafe-loop-optimizations: Optimize Options. (line 495) |
| * funsafe-math-optimizations: Optimize Options. (line 1948) |
| * 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 328) |
| * funsigned-char <1>: Characters implementation. |
| (line 31) |
| * funsigned-char: C Dialect Options. (line 300) |
| * funswitch-loops: Optimize Options. (line 2184) |
| * funwind-tables: Code Gen Options. (line 57) |
| * fuse-cxa-atexit: C++ Dialect Options. |
| (line 246) |
| * fvar-tracking: Debugging Options. (line 1116) |
| * fvar-tracking-assignments: Debugging Options. (line 1126) |
| * fvar-tracking-assignments-toggle: Debugging Options. (line 1136) |
| * fvariable-expansion-in-unroller: Optimize Options. (line 1227) |
| * fvect-cost-model: Optimize Options. (line 1184) |
| * fverbose-asm: Code Gen Options. (line 165) |
| * fvisibility: Code Gen Options. (line 451) |
| * fvisibility-inlines-hidden: C++ Dialect Options. |
| (line 258) |
| * fvisibility-ms-compat: C++ Dialect Options. |
| (line 286) |
| * fvpt: Optimize Options. (line 2130) |
| * fweb: Optimize Options. (line 1476) |
| * fwhole-program: Optimize Options. (line 1487) |
| * fwide-exec-charset: Preprocessor Options. |
| (line 513) |
| * fworking-directory: Preprocessor Options. |
| (line 531) |
| * fwrapv: Code Gen Options. (line 26) |
| * fzero-link: Objective-C and Objective-C++ Dialect Options. |
| (line 141) |
| * G <1>: System V Options. (line 10) |
| * G <2>: RS/6000 and PowerPC Options. |
| (line 703) |
| * G <3>: MIPS Options. (line 315) |
| * G: M32R/D Options. (line 57) |
| * g: Debugging Options. (line 10) |
| * gcoff: Debugging Options. (line 70) |
| * gdwarf-VERSION: Debugging Options. (line 88) |
| * gen-decls: Objective-C and Objective-C++ Dialect Options. |
| (line 153) |
| * gfull: Darwin Options. (line 71) |
| * ggdb: Debugging Options. (line 38) |
| * gmlt: Debugging Options. (line 142) |
| * gno-strict-dwarf: Debugging Options. (line 105) |
| * gstabs: Debugging Options. (line 44) |
| * gstabs+: Debugging Options. (line 64) |
| * gstrict-dwarf: Debugging Options. (line 99) |
| * gtoggle: Debugging Options. (line 146) |
| * gused: Darwin Options. (line 66) |
| * gvms: Debugging Options. (line 109) |
| * gxcoff: Debugging Options. (line 75) |
| * gxcoff+: Debugging Options. (line 80) |
| * H: Preprocessor Options. |
| (line 664) |
| * headerpad_max_install_names: Darwin Options. (line 199) |
| * help <1>: Preprocessor Options. |
| (line 656) |
| * help: Overall Options. (line 221) |
| * I <1>: Directory Options. (line 10) |
| * I: Preprocessor Options. |
| (line 65) |
| * I- <1>: Directory Options. (line 112) |
| * I-: Preprocessor Options. |
| (line 373) |
| * idirafter: Preprocessor Options. |
| (line 415) |
| * iframework: Darwin Options. (line 59) |
| * imacros: Preprocessor Options. |
| (line 406) |
| * image_base: Darwin Options. (line 199) |
| * imultilib: Preprocessor Options. |
| (line 440) |
| * include: Preprocessor Options. |
| (line 395) |
| * init: Darwin Options. (line 199) |
| * install_name: Darwin Options. (line 199) |
| * iprefix: Preprocessor Options. |
| (line 422) |
| * iquote <1>: Directory Options. (line 36) |
| * iquote: Preprocessor Options. |
| (line 452) |
| * isysroot: Preprocessor Options. |
| (line 434) |
| * isystem: Preprocessor Options. |
| (line 444) |
| * iwithprefix: Preprocessor Options. |
| (line 428) |
| * iwithprefixbefore: Preprocessor Options. |
| (line 428) |
| * keep_private_externs: Darwin Options. (line 199) |
| * L: Directory Options. (line 42) |
| * l: Link Options. (line 26) |
| * lobjc: Link Options. (line 53) |
| * m: RS/6000 and PowerPC Options. |
| (line 552) |
| * 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 283) |
| * m16-bit: CRIS Options. (line 64) |
| * m2: SH Options. (line 12) |
| * m210: MCore Options. (line 43) |
| * m2a: SH Options. (line 30) |
| * m2a-nofpu: SH Options. (line 18) |
| * m2a-single: SH Options. (line 26) |
| * m2a-single-only: SH Options. (line 22) |
| * m3: SH Options. (line 34) |
| * m31: S/390 and zSeries Options. |
| (line 87) |
| * m32 <1>: SPARC Options. (line 182) |
| * m32 <2>: RS/6000 and PowerPC Options. |
| (line 266) |
| * m32: i386 and x86-64 Options. |
| (line 697) |
| * m32-bit: CRIS Options. (line 64) |
| * m32bit-doubles: RX Options. (line 10) |
| * m32r: M32R/D Options. (line 15) |
| * m32r2: M32R/D Options. (line 9) |
| * m32rx: M32R/D Options. (line 12) |
| * m340: MCore Options. (line 43) |
| * m3dnow: i386 and x86-64 Options. |
| (line 477) |
| * m3e: SH Options. (line 37) |
| * m4: SH Options. (line 51) |
| * m4-nofpu: SH Options. (line 40) |
| * m4-single: SH Options. (line 47) |
| * m4-single-only: SH Options. (line 43) |
| * m40: PDP-11 Options. (line 23) |
| * m45: PDP-11 Options. (line 26) |
| * m4a: SH Options. (line 66) |
| * m4a-nofpu: SH Options. (line 54) |
| * m4a-single: SH Options. (line 62) |
| * m4a-single-only: SH Options. (line 58) |
| * m4al: SH Options. (line 69) |
| * m4byte-functions: MCore Options. (line 27) |
| * m5200: M680x0 Options. (line 146) |
| * m5206e: M680x0 Options. (line 155) |
| * m528x: M680x0 Options. (line 159) |
| * m5307: M680x0 Options. (line 163) |
| * m5407: M680x0 Options. (line 167) |
| * m64 <1>: SPARC Options. (line 182) |
| * m64 <2>: S/390 and zSeries Options. |
| (line 87) |
| * m64 <3>: RS/6000 and PowerPC Options. |
| (line 266) |
| * m64: i386 and x86-64 Options. |
| (line 697) |
| * m64bit-doubles: RX Options. (line 10) |
| * m68000: M680x0 Options. (line 94) |
| * m68010: M680x0 Options. (line 102) |
| * m68020: M680x0 Options. (line 108) |
| * m68020-40: M680x0 Options. (line 177) |
| * m68020-60: M680x0 Options. (line 186) |
| * m68030: M680x0 Options. (line 113) |
| * m68040: M680x0 Options. (line 118) |
| * m68060: M680x0 Options. (line 127) |
| * m6811: M68hc1x Options. (line 13) |
| * m6812: M68hc1x Options. (line 18) |
| * m68881: M680x0 Options. (line 196) |
| * 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 283) |
| * mabi <1>: RS/6000 and PowerPC Options. |
| (line 583) |
| * mabi <2>: i386 and x86-64 Options. |
| (line 592) |
| * mabi: ARM Options. (line 10) |
| * mabi=32: MIPS Options. (line 130) |
| * mabi=64: MIPS Options. (line 130) |
| * mabi=eabi: MIPS Options. (line 130) |
| * mabi=gnu: MMIX Options. (line 20) |
| * mabi=ibmlongdouble: RS/6000 and PowerPC Options. |
| (line 596) |
| * mabi=ieeelongdouble: RS/6000 and PowerPC Options. |
| (line 600) |
| * mabi=mmixware: MMIX Options. (line 20) |
| * mabi=n32: MIPS Options. (line 130) |
| * mabi=no-spe: RS/6000 and PowerPC Options. |
| (line 593) |
| * mabi=o64: MIPS Options. (line 130) |
| * mabi=spe: RS/6000 and PowerPC Options. |
| (line 588) |
| * mabicalls: MIPS Options. (line 154) |
| * mabort-on-noreturn: ARM Options. (line 162) |
| * mabsdiff: MeP Options. (line 7) |
| * 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 <1>: SH Options. (line 199) |
| * maccumulate-outgoing-args: i386 and x86-64 Options. |
| (line 609) |
| * maddress-space-conversion: SPU Options. (line 63) |
| * madjust-unroll: SH Options. (line 219) |
| * mads: RS/6000 and PowerPC Options. |
| (line 626) |
| * maix-struct-return: RS/6000 and PowerPC Options. |
| (line 576) |
| * maix32: RS/6000 and PowerPC Options. |
| (line 304) |
| * maix64: RS/6000 and PowerPC Options. |
| (line 304) |
| * malign-300: H8/300 Options. (line 31) |
| * malign-double: i386 and x86-64 Options. |
| (line 267) |
| * malign-int: M680x0 Options. (line 266) |
| * malign-labels: FRV Options. (line 104) |
| * malign-loops: M32R/D Options. (line 73) |
| * malign-natural: RS/6000 and PowerPC Options. |
| (line 343) |
| * malign-power: RS/6000 and PowerPC Options. |
| (line 343) |
| * mall-opts: MeP Options. (line 11) |
| * malloc-cc: FRV Options. (line 25) |
| * malpha-as: DEC Alpha Options. (line 159) |
| * maltivec: RS/6000 and PowerPC Options. |
| (line 191) |
| * mam33: MN10300 Options. (line 17) |
| * mam33-2: MN10300 Options. (line 24) |
| * mam34: MN10300 Options. (line 28) |
| * mandroid: GNU/Linux Options. (line 21) |
| * 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 166) |
| * march <5>: HPPA Options. (line 9) |
| * march <6>: CRIS Options. (line 10) |
| * march: ARM Options. (line 108) |
| * mas100-syntax: RX Options. (line 75) |
| * masm=DIALECT: i386 and x86-64 Options. |
| (line 223) |
| * matomic-updates: SPU Options. (line 78) |
| * mauto-incdec: M68hc1x Options. (line 26) |
| * mauto-pic: IA-64 Options. (line 50) |
| * maverage: MeP Options. (line 16) |
| * mavoid-indexed-addresses: RS/6000 and PowerPC Options. |
| (line 412) |
| * mb: SH Options. (line 74) |
| * mbackchain: S/390 and zSeries Options. |
| (line 35) |
| * mbarrel-shift-enabled: LM32 Options. (line 9) |
| * mbase-addresses: MMIX Options. (line 54) |
| * mbased=: MeP Options. (line 20) |
| * mbcopy: PDP-11 Options. (line 36) |
| * mbcopy-builtin: PDP-11 Options. (line 32) |
| * mbig: RS/6000 and PowerPC Options. |
| (line 493) |
| * mbig-endian <1>: RS/6000 and PowerPC Options. |
| (line 493) |
| * mbig-endian <2>: MCore Options. (line 39) |
| * mbig-endian <3>: IA-64 Options. (line 9) |
| * mbig-endian: ARM Options. (line 67) |
| * mbig-endian-data: RX Options. (line 42) |
| * mbig-switch <1>: V850 Options. (line 52) |
| * mbig-switch: HPPA Options. (line 23) |
| * mbigtable: SH Options. (line 90) |
| * mbionic: GNU/Linux Options. (line 17) |
| * mbit-align: RS/6000 and PowerPC Options. |
| (line 444) |
| * mbitfield: M680x0 Options. (line 234) |
| * mbitops <1>: SH Options. (line 94) |
| * mbitops: MeP Options. (line 26) |
| * mblock-move-inline-limit: RS/6000 and PowerPC Options. |
| (line 697) |
| * mbranch-cheap: PDP-11 Options. (line 65) |
| * mbranch-cost: MIPS Options. (line 611) |
| * 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 618) |
| * mbranch-predict: MMIX Options. (line 49) |
| * mbss-plt: RS/6000 and PowerPC Options. |
| (line 214) |
| * mbuild-constants: DEC Alpha Options. (line 142) |
| * mbwx: DEC Alpha Options. (line 171) |
| * mc68000: M680x0 Options. (line 94) |
| * mc68020: M680x0 Options. (line 108) |
| * mc=: MeP Options. (line 31) |
| * mcache-size: SPU Options. (line 70) |
| * mcall-eabi: RS/6000 and PowerPC Options. |
| (line 546) |
| * mcall-freebsd: RS/6000 and PowerPC Options. |
| (line 564) |
| * mcall-gnu: RS/6000 and PowerPC Options. |
| (line 560) |
| * mcall-linux: RS/6000 and PowerPC Options. |
| (line 556) |
| * mcall-netbsd: RS/6000 and PowerPC Options. |
| (line 568) |
| * mcall-prologues: AVR Options. (line 36) |
| * mcall-sysv: RS/6000 and PowerPC Options. |
| (line 538) |
| * mcall-sysv-eabi: RS/6000 and PowerPC Options. |
| (line 546) |
| * mcall-sysv-noeabi: RS/6000 and PowerPC Options. |
| (line 549) |
| * mcallee-super-interworking: ARM Options. (line 255) |
| * mcaller-super-interworking: ARM Options. (line 262) |
| * mcallgraph-data: MCore Options. (line 31) |
| * mcc-init: CRIS Options. (line 41) |
| * mcfv4e: M680x0 Options. (line 171) |
| * mcheck-zero-division: MIPS Options. (line 426) |
| * mcirrus-fix-invalid-insns: ARM Options. (line 202) |
| * mcix: DEC Alpha Options. (line 171) |
| * mcld: i386 and x86-64 Options. |
| (line 506) |
| * mclip: MeP Options. (line 35) |
| * mcmodel=embmedany: SPARC Options. (line 204) |
| * mcmodel=kernel: i386 and x86-64 Options. |
| (line 719) |
| * mcmodel=large <1>: RS/6000 and PowerPC Options. |
| (line 185) |
| * mcmodel=large: i386 and x86-64 Options. |
| (line 731) |
| * mcmodel=medany: SPARC Options. (line 198) |
| * mcmodel=medium <1>: RS/6000 and PowerPC Options. |
| (line 181) |
| * mcmodel=medium: i386 and x86-64 Options. |
| (line 724) |
| * mcmodel=medlow: SPARC Options. (line 187) |
| * mcmodel=medmid: SPARC Options. (line 192) |
| * mcmodel=small <1>: RS/6000 and PowerPC Options. |
| (line 177) |
| * mcmodel=small: i386 and x86-64 Options. |
| (line 713) |
| * mcmpb: RS/6000 and PowerPC Options. |
| (line 33) |
| * mcode-readable: MIPS Options. (line 386) |
| * mcond-exec: FRV Options. (line 152) |
| * mcond-move: FRV Options. (line 128) |
| * mconfig=: MeP Options. (line 39) |
| * mconsole: i386 and x86-64 Windows Options. |
| (line 9) |
| * mconst-align: CRIS Options. (line 55) |
| * mconst16: Xtensa Options. (line 10) |
| * mconstant-gp: IA-64 Options. (line 46) |
| * mcop: MeP Options. (line 48) |
| * mcop32: MeP Options. (line 53) |
| * mcop64: MeP Options. (line 56) |
| * mcorea: Blackfin Options. (line 150) |
| * mcoreb: Blackfin Options. (line 156) |
| * mcpu <1>: SPARC Options. (line 81) |
| * mcpu <2>: RS/6000 and PowerPC Options. |
| (line 119) |
| * mcpu <3>: picoChip Options. (line 9) |
| * mcpu <4>: M680x0 Options. (line 28) |
| * mcpu <5>: i386 and x86-64 Options. |
| (line 171) |
| * mcpu <6>: FRV Options. (line 212) |
| * mcpu <7>: DEC Alpha Options. (line 223) |
| * mcpu <8>: CRIS Options. (line 10) |
| * mcpu <9>: ARM Options. (line 79) |
| * mcpu: ARC Options. (line 23) |
| * mcpu32: M680x0 Options. (line 137) |
| * mcpu= <1>: MicroBlaze Options. (line 20) |
| * mcpu= <2>: M32C Options. (line 7) |
| * mcpu=: Blackfin Options. (line 7) |
| * mcrc32: i386 and x86-64 Options. |
| (line 548) |
| * mcsync-anomaly: Blackfin Options. (line 56) |
| * mcx16: i386 and x86-64 Options. |
| (line 526) |
| * MD: Preprocessor Options. |
| (line 262) |
| * mdalign: SH Options. (line 80) |
| * mdata: ARC Options. (line 30) |
| * mdata-align: CRIS Options. (line 55) |
| * mdc: MeP Options. (line 62) |
| * mdebug <1>: S/390 and zSeries Options. |
| (line 112) |
| * mdebug: M32R/D Options. (line 69) |
| * mdebug-main=PREFIX <1>: IA-64/VMS Options. (line 13) |
| * mdebug-main=PREFIX: DEC Alpha/VMS Options. |
| (line 13) |
| * mdec-asm: PDP-11 Options. (line 72) |
| * mdisable-callt: V850 Options. (line 93) |
| * mdisable-fpregs: HPPA Options. (line 33) |
| * mdisable-indexing: HPPA Options. (line 40) |
| * mdiv <1>: MeP Options. (line 65) |
| * mdiv <2>: MCore Options. (line 15) |
| * mdiv: M680x0 Options. (line 208) |
| * mdiv=STRATEGY: SH Options. (line 158) |
| * mdivide-breaks: MIPS Options. (line 432) |
| * mdivide-enabled: LM32 Options. (line 12) |
| * mdivide-traps: MIPS Options. (line 432) |
| * mdivsi3_libfunc=NAME: SH Options. (line 205) |
| * mdll: i386 and x86-64 Windows Options. |
| (line 16) |
| * mdlmzb: RS/6000 and PowerPC Options. |
| (line 437) |
| * mdmx: MIPS Options. (line 279) |
| * mdouble: FRV Options. (line 38) |
| * mdouble-float <1>: RS/6000 and PowerPC Options. |
| (line 361) |
| * mdouble-float: MIPS Options. (line 237) |
| * mdsp: MIPS Options. (line 256) |
| * mdspr2: MIPS Options. (line 262) |
| * mdual-nops: SPU Options. (line 90) |
| * mdwarf2-asm: IA-64 Options. (line 94) |
| * mdword: FRV Options. (line 32) |
| * mdynamic-no-pic: RS/6000 and PowerPC Options. |
| (line 498) |
| * mea32: SPU Options. (line 55) |
| * mea64: SPU Options. (line 55) |
| * meabi: RS/6000 and PowerPC Options. |
| (line 645) |
| * mearly-stop-bits: IA-64 Options. (line 100) |
| * meb <1>: Score Options. (line 9) |
| * meb: MeP Options. (line 68) |
| * mel <1>: Score Options. (line 12) |
| * mel: MeP Options. (line 71) |
| * melf <1>: MMIX Options. (line 44) |
| * melf: CRIS Options. (line 87) |
| * memb: RS/6000 and PowerPC Options. |
| (line 640) |
| * membedded-data: MIPS Options. (line 373) |
| * 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 417) |
| * mexplicit-relocs: DEC Alpha Options. (line 184) |
| * mextern-sdata: MIPS Options. (line 335) |
| * MF: Preprocessor Options. |
| (line 208) |
| * mfast-fp: Blackfin Options. (line 129) |
| * mfast-indirect-calls: HPPA Options. (line 52) |
| * mfaster-structs: SPARC Options. (line 71) |
| * mfdpic: FRV Options. (line 56) |
| * mfentry: i386 and x86-64 Options. |
| (line 673) |
| * mfix: DEC Alpha Options. (line 171) |
| * mfix-and-continue: Darwin Options. (line 106) |
| * mfix-at697f: SPARC Options. (line 168) |
| * mfix-cortex-m3-ldrd: ARM Options. (line 284) |
| * mfix-r10000: MIPS Options. (line 503) |
| * mfix-r4000: MIPS Options. (line 482) |
| * mfix-r4400: MIPS Options. (line 496) |
| * mfix-sb1: MIPS Options. (line 535) |
| * mfix-vr4120: MIPS Options. (line 514) |
| * mfix-vr4130: MIPS Options. (line 528) |
| * mfixed-cc: FRV Options. (line 28) |
| * mfixed-range <1>: SPU Options. (line 47) |
| * mfixed-range <2>: SH Options. (line 212) |
| * mfixed-range <3>: IA-64 Options. (line 105) |
| * mfixed-range: HPPA Options. (line 59) |
| * mflip-mips16: MIPS Options. (line 110) |
| * mfloat-abi: ARM Options. (line 41) |
| * mfloat-gprs: RS/6000 and PowerPC Options. |
| (line 249) |
| * 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 602) |
| * mflush-func=NAME: M32R/D Options. (line 94) |
| * mflush-trap=NUMBER: M32R/D Options. (line 87) |
| * mfmovd: SH Options. (line 97) |
| * mforce-no-pic: Xtensa Options. (line 41) |
| * mfp: ARM Options. (line 120) |
| * mfp-exceptions: MIPS Options. (line 629) |
| * mfp-reg: DEC Alpha Options. (line 25) |
| * mfp-rounding-mode: DEC Alpha Options. (line 85) |
| * mfp-trap-mode: DEC Alpha Options. (line 63) |
| * mfp16-format: ARM Options. (line 141) |
| * mfp32: MIPS Options. (line 220) |
| * mfp64: MIPS Options. (line 223) |
| * mfpe: ARM Options. (line 120) |
| * mfpmath <1>: i386 and x86-64 Options. |
| (line 174) |
| * mfpmath: Optimize Options. (line 1908) |
| * mfpr-32: FRV Options. (line 13) |
| * mfpr-64: FRV Options. (line 16) |
| * mfprnd: RS/6000 and PowerPC Options. |
| (line 33) |
| * mfpu <1>: SPARC Options. (line 20) |
| * mfpu <2>: RS/6000 and PowerPC Options. |
| (line 369) |
| * mfpu <3>: PDP-11 Options. (line 9) |
| * mfpu: ARM Options. (line 120) |
| * mfriz: RS/6000 and PowerPC Options. |
| (line 827) |
| * mfull-toc: RS/6000 and PowerPC Options. |
| (line 277) |
| * 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 421) |
| * mfused-madd <4>: MIPS Options. (line 467) |
| * mfused-madd <5>: IA-64 Options. (line 88) |
| * mfused-madd: i386 and x86-64 Options. |
| (line 501) |
| * 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 202) |
| * mgettrcost=NUMBER: SH Options. (line 234) |
| * mglibc: GNU/Linux Options. (line 9) |
| * mgnu: VAX Options. (line 13) |
| * mgnu-as: IA-64 Options. (line 18) |
| * mgnu-ld <1>: IA-64 Options. (line 23) |
| * mgnu-ld: HPPA Options. (line 111) |
| * mgotplt: CRIS Options. (line 81) |
| * mgp32: MIPS Options. (line 214) |
| * mgp64: MIPS Options. (line 217) |
| * mgpopt: MIPS Options. (line 358) |
| * 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 33) |
| * 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 355) |
| * mhard-float <4>: MIPS Options. (line 226) |
| * mhard-float <5>: MicroBlaze Options. (line 10) |
| * mhard-float <6>: M680x0 Options. (line 196) |
| * mhard-float <7>: FRV Options. (line 19) |
| * mhard-float: ARM Options. (line 57) |
| * mhard-quad-float: SPARC Options. (line 41) |
| * mhardlit: MCore Options. (line 10) |
| * mhint-max-distance: SPU Options. (line 102) |
| * mhint-max-nops: SPU Options. (line 96) |
| * mhitachi: SH Options. (line 101) |
| * mhp-ld: HPPA Options. (line 123) |
| * micplb: Blackfin Options. (line 169) |
| * mid-shared-library: Blackfin Options. (line 77) |
| * mieee <1>: SH Options. (line 116) |
| * mieee: DEC Alpha Options. (line 39) |
| * mieee-conformant: DEC Alpha Options. (line 134) |
| * mieee-fp: i386 and x86-64 Options. |
| (line 229) |
| * mieee-with-inexact: DEC Alpha Options. (line 52) |
| * milp32: IA-64 Options. (line 121) |
| * mimpure-text: Solaris 2 Options. (line 9) |
| * mincoming-stack-boundary: i386 and x86-64 Options. |
| (line 407) |
| * mindexed-addressing: SH Options. (line 224) |
| * minline-all-stringops: i386 and x86-64 Options. |
| (line 630) |
| * 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 123) |
| * minline-int-divide-max-throughput: IA-64 Options. (line 69) |
| * minline-int-divide-min-latency: IA-64 Options. (line 65) |
| * minline-plt <1>: FRV Options. (line 64) |
| * minline-plt: Blackfin Options. (line 134) |
| * minline-sqrt-max-throughput: IA-64 Options. (line 80) |
| * minline-sqrt-min-latency: IA-64 Options. (line 76) |
| * minline-stringops-dynamically: i386 and x86-64 Options. |
| (line 637) |
| * minmax: M68hc1x Options. (line 31) |
| * minsert-sched-nops: RS/6000 and PowerPC Options. |
| (line 526) |
| * mint-register: RX Options. (line 99) |
| * mint16: PDP-11 Options. (line 40) |
| * mint32 <1>: PDP-11 Options. (line 44) |
| * mint32: H8/300 Options. (line 28) |
| * mint8: AVR Options. (line 43) |
| * minterlink-mips16: MIPS Options. (line 117) |
| * minvalid-symbols: SH Options. (line 257) |
| * mio-volatile: MeP Options. (line 74) |
| * mips1: MIPS Options. (line 77) |
| * mips16: MIPS Options. (line 102) |
| * mips2: MIPS Options. (line 80) |
| * mips3: MIPS Options. (line 83) |
| * mips32: MIPS Options. (line 89) |
| * mips32r2: MIPS Options. (line 92) |
| * mips3d: MIPS Options. (line 285) |
| * mips4: MIPS Options. (line 86) |
| * mips64: MIPS Options. (line 95) |
| * mips64r2: MIPS Options. (line 98) |
| * misel: RS/6000 and PowerPC Options. |
| (line 220) |
| * misize: SH Options. (line 135) |
| * missue-rate=NUMBER: M32R/D Options. (line 79) |
| * mivc2: MeP Options. (line 59) |
| * mjump-in-delay: HPPA Options. (line 28) |
| * mkernel: Darwin Options. (line 84) |
| * mknuthdiv: MMIX Options. (line 33) |
| * ml <1>: SH Options. (line 77) |
| * ml: MeP Options. (line 78) |
| * mlarge-data: DEC Alpha Options. (line 195) |
| * mlarge-data-threshold=NUMBER: i386 and x86-64 Options. |
| (line 309) |
| * mlarge-mem: SPU Options. (line 35) |
| * mlarge-text: DEC Alpha Options. (line 213) |
| * mleadz: MeP Options. (line 81) |
| * mleaf-id-shared-library: Blackfin Options. (line 88) |
| * 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 487) |
| * mlittle-endian <1>: SPARC Options. (line 176) |
| * mlittle-endian <2>: RS/6000 and PowerPC Options. |
| (line 487) |
| * mlittle-endian <3>: MCore Options. (line 39) |
| * mlittle-endian <4>: IA-64 Options. (line 13) |
| * mlittle-endian: ARM Options. (line 63) |
| * mlittle-endian-data: RX Options. (line 42) |
| * mliw: MN10300 Options. (line 55) |
| * mllsc: MIPS Options. (line 242) |
| * mlocal-sdata: MIPS Options. (line 323) |
| * mlong-calls <1>: V850 Options. (line 10) |
| * mlong-calls <2>: MIPS Options. (line 453) |
| * mlong-calls <3>: M68hc1x Options. (line 35) |
| * mlong-calls <4>: FRV Options. (line 99) |
| * mlong-calls <5>: Blackfin Options. (line 117) |
| * mlong-calls: ARM Options. (line 167) |
| * 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 298) |
| * mlong64: MIPS Options. (line 293) |
| * mlongcall: RS/6000 and PowerPC Options. |
| (line 717) |
| * mlongcalls: Xtensa Options. (line 72) |
| * mlow-64k: Blackfin Options. (line 66) |
| * mlp64: IA-64 Options. (line 121) |
| * mm: MeP Options. (line 84) |
| * MM: Preprocessor Options. |
| (line 198) |
| * mmac <1>: Score Options. (line 21) |
| * mmac: CRX Options. (line 9) |
| * mmad: MIPS Options. (line 462) |
| * mmalloc64 <1>: IA-64/VMS Options. (line 17) |
| * mmalloc64: DEC Alpha/VMS Options. |
| (line 17) |
| * mmangle-cpu: ARC Options. (line 15) |
| * mmax: DEC Alpha Options. (line 171) |
| * mmax-constant-size: RX Options. (line 81) |
| * mmax-stack-frame: CRIS Options. (line 22) |
| * mmcount-ra-address: MIPS Options. (line 678) |
| * mmcu: AVR Options. (line 9) |
| * MMD: Preprocessor Options. |
| (line 278) |
| * mmedia: FRV Options. (line 44) |
| * mmemcpy <1>: MIPS Options. (line 447) |
| * mmemcpy: MicroBlaze Options. (line 13) |
| * mmemory-latency: DEC Alpha Options. (line 276) |
| * mmfcrf: RS/6000 and PowerPC Options. |
| (line 33) |
| * mmfpgpr: RS/6000 and PowerPC Options. |
| (line 33) |
| * mminimal-toc: RS/6000 and PowerPC Options. |
| (line 277) |
| * mminmax: MeP Options. (line 87) |
| * mmmx: i386 and x86-64 Options. |
| (line 477) |
| * mmodel=large: M32R/D Options. (line 33) |
| * mmodel=medium: M32R/D Options. (line 27) |
| * mmodel=small: M32R/D Options. (line 18) |
| * mmovbe: i386 and x86-64 Options. |
| (line 544) |
| * mmt: MIPS Options. (line 290) |
| * mmul-bug-workaround: CRIS Options. (line 31) |
| * mmuladd: FRV Options. (line 50) |
| * mmulhw: RS/6000 and PowerPC Options. |
| (line 430) |
| * mmult: MeP Options. (line 90) |
| * mmult-bug: MN10300 Options. (line 9) |
| * mmulti-cond-exec: FRV Options. (line 176) |
| * mmulticore: Blackfin Options. (line 138) |
| * mmultiple: RS/6000 and PowerPC Options. |
| (line 380) |
| * mmvcle: S/390 and zSeries Options. |
| (line 105) |
| * mmvme: RS/6000 and PowerPC Options. |
| (line 621) |
| * mn: H8/300 Options. (line 20) |
| * mnested-cond-exec: FRV Options. (line 189) |
| * mnew-mnemonics: RS/6000 and PowerPC Options. |
| (line 104) |
| * mnhwloop: Score Options. (line 15) |
| * mno-3dnow: i386 and x86-64 Options. |
| (line 477) |
| * mno-4byte-functions: MCore Options. (line 27) |
| * mno-abicalls: MIPS Options. (line 154) |
| * mno-abshi: PDP-11 Options. (line 58) |
| * mno-ac0: PDP-11 Options. (line 20) |
| * mno-address-space-conversion: SPU Options. (line 63) |
| * mno-align-double: i386 and x86-64 Options. |
| (line 267) |
| * mno-align-int: M680x0 Options. (line 266) |
| * mno-align-loops: M32R/D Options. (line 76) |
| * mno-align-stringops: i386 and x86-64 Options. |
| (line 625) |
| * mno-altivec: RS/6000 and PowerPC Options. |
| (line 191) |
| * mno-am33: MN10300 Options. (line 20) |
| * mno-app-regs <1>: V850 Options. (line 61) |
| * mno-app-regs: SPARC Options. (line 10) |
| * mno-as100-syntax: RX Options. (line 75) |
| * mno-atomic-updates: SPU Options. (line 78) |
| * mno-avoid-indexed-addresses: RS/6000 and PowerPC Options. |
| (line 412) |
| * 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 444) |
| * mno-bitfield: M680x0 Options. (line 230) |
| * mno-branch-likely: MIPS Options. (line 618) |
| * 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 426) |
| * mno-cirrus-fix-invalid-insns: ARM Options. (line 202) |
| * mno-cix: DEC Alpha Options. (line 171) |
| * mno-clearbss: MicroBlaze Options. (line 16) |
| * mno-cmpb: RS/6000 and PowerPC Options. |
| (line 33) |
| * 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 44) |
| * mno-csync-anomaly: Blackfin Options. (line 62) |
| * 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 208) |
| * mno-dlmzb: RS/6000 and PowerPC Options. |
| (line 437) |
| * mno-double: FRV Options. (line 41) |
| * mno-dsp: MIPS Options. (line 256) |
| * mno-dspr2: MIPS Options. (line 262) |
| * mno-dwarf2-asm: IA-64 Options. (line 94) |
| * mno-dword: FRV Options. (line 35) |
| * mno-eabi: RS/6000 and PowerPC Options. |
| (line 645) |
| * mno-early-stop-bits: IA-64 Options. (line 100) |
| * mno-eflags: FRV Options. (line 125) |
| * mno-embedded-data: MIPS Options. (line 373) |
| * mno-ep: V850 Options. (line 16) |
| * mno-epsilon: MMIX Options. (line 15) |
| * mno-explicit-relocs <1>: MIPS Options. (line 417) |
| * mno-explicit-relocs: DEC Alpha Options. (line 184) |
| * mno-extern-sdata: MIPS Options. (line 335) |
| * mno-fancy-math-387: i386 and x86-64 Options. |
| (line 256) |
| * mno-faster-structs: SPARC Options. (line 71) |
| * mno-fix: DEC Alpha Options. (line 171) |
| * mno-fix-r10000: MIPS Options. (line 503) |
| * mno-fix-r4000: MIPS Options. (line 482) |
| * mno-fix-r4400: MIPS Options. (line 496) |
| * 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 277) |
| * mno-fp-regs: DEC Alpha Options. (line 25) |
| * mno-fp-ret-in-387: i386 and x86-64 Options. |
| (line 246) |
| * mno-fprnd: RS/6000 and PowerPC Options. |
| (line 33) |
| * 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 421) |
| * mno-fused-madd <4>: MIPS Options. (line 467) |
| * mno-fused-madd <5>: IA-64 Options. (line 88) |
| * mno-fused-madd: i386 and x86-64 Options. |
| (line 501) |
| * 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 358) |
| * mno-hard-dfp <1>: S/390 and zSeries Options. |
| (line 20) |
| * mno-hard-dfp: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-hardlit: MCore Options. (line 10) |
| * mno-id-shared-library: Blackfin Options. (line 84) |
| * mno-ieee-fp: i386 and x86-64 Options. |
| (line 229) |
| * mno-inline-float-divide: IA-64 Options. (line 62) |
| * mno-inline-int-divide: IA-64 Options. (line 73) |
| * mno-inline-sqrt: IA-64 Options. (line 84) |
| * mno-int16: PDP-11 Options. (line 44) |
| * mno-int32: PDP-11 Options. (line 40) |
| * mno-interlink-mips16: MIPS Options. (line 117) |
| * mno-interrupts: AVR Options. (line 32) |
| * mno-isel: RS/6000 and PowerPC Options. |
| (line 220) |
| * mno-knuthdiv: MMIX Options. (line 33) |
| * mno-leaf-id-shared-library: Blackfin Options. (line 94) |
| * mno-libfuncs: MMIX Options. (line 10) |
| * mno-llsc: MIPS Options. (line 242) |
| * mno-local-sdata: MIPS Options. (line 323) |
| * mno-long-calls <1>: V850 Options. (line 10) |
| * mno-long-calls <2>: MIPS Options. (line 453) |
| * mno-long-calls <3>: M68hc1x Options. (line 35) |
| * mno-long-calls <4>: HPPA Options. (line 136) |
| * mno-long-calls <5>: Blackfin Options. (line 117) |
| * mno-long-calls: ARM Options. (line 167) |
| * mno-longcall: RS/6000 and PowerPC Options. |
| (line 717) |
| * mno-longcalls: Xtensa Options. (line 72) |
| * mno-low-64k: Blackfin Options. (line 70) |
| * mno-lsim <1>: MCore Options. (line 46) |
| * mno-lsim: FR30 Options. (line 14) |
| * mno-mad: MIPS Options. (line 462) |
| * mno-max: DEC Alpha Options. (line 171) |
| * mno-mcount-ra-address: MIPS Options. (line 678) |
| * mno-mdmx: MIPS Options. (line 279) |
| * mno-media: FRV Options. (line 47) |
| * mno-memcpy: MIPS Options. (line 447) |
| * mno-mfcrf: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-mfpgpr: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-mips16: MIPS Options. (line 102) |
| * mno-mips3d: MIPS Options. (line 285) |
| * mno-mmx: i386 and x86-64 Options. |
| (line 477) |
| * mno-mt: MIPS Options. (line 290) |
| * mno-mul-bug-workaround: CRIS Options. (line 31) |
| * mno-muladd: FRV Options. (line 53) |
| * mno-mulhw: RS/6000 and PowerPC Options. |
| (line 430) |
| * mno-mult-bug: MN10300 Options. (line 13) |
| * mno-multi-cond-exec: FRV Options. (line 183) |
| * mno-multiple: RS/6000 and PowerPC Options. |
| (line 380) |
| * 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-opts: MeP Options. (line 93) |
| * mno-pack: FRV Options. (line 122) |
| * mno-packed-stack: S/390 and zSeries Options. |
| (line 54) |
| * mno-paired: RS/6000 and PowerPC Options. |
| (line 234) |
| * mno-paired-single: MIPS Options. (line 273) |
| * mno-pic: IA-64 Options. (line 26) |
| * mno-plt: MIPS Options. (line 181) |
| * mno-popcntb: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-popcntd: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-power: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-power2: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-powerpc: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-powerpc-gfxopt: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-powerpc-gpopt: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-powerpc64: RS/6000 and PowerPC Options. |
| (line 33) |
| * mno-prolog-function: V850 Options. (line 23) |
| * mno-prologue-epilogue: CRIS Options. (line 71) |
| * mno-prototype: RS/6000 and PowerPC Options. |
| (line 605) |
| * mno-push-args: i386 and x86-64 Options. |
| (line 602) |
| * mno-red-zone: i386 and x86-64 Options. |
| (line 705) |
| * mno-register-names: IA-64 Options. (line 37) |
| * mno-regnames: RS/6000 and PowerPC Options. |
| (line 711) |
| * mno-relax-immediate: MCore Options. (line 19) |
| * mno-relocatable: RS/6000 and PowerPC Options. |
| (line 461) |
| * mno-relocatable-lib: RS/6000 and PowerPC Options. |
| (line 472) |
| * mno-rtd: M680x0 Options. (line 261) |
| * mno-scc: FRV Options. (line 146) |
| * mno-sched-ar-data-spec: IA-64 Options. (line 135) |
| * mno-sched-ar-in-data-spec: IA-64 Options. (line 156) |
| * mno-sched-br-data-spec: IA-64 Options. (line 128) |
| * mno-sched-br-in-data-spec: IA-64 Options. (line 149) |
| * mno-sched-control-spec: IA-64 Options. (line 142) |
| * mno-sched-count-spec-in-critical-path: IA-64 Options. (line 183) |
| * mno-sched-in-control-spec: IA-64 Options. (line 163) |
| * mno-sched-prefer-non-control-spec-insns: IA-64 Options. (line 176) |
| * mno-sched-prefer-non-data-spec-insns: IA-64 Options. (line 169) |
| * mno-sched-prolog: ARM Options. (line 32) |
| * mno-sdata <1>: RS/6000 and PowerPC Options. |
| (line 692) |
| * mno-sdata: IA-64 Options. (line 42) |
| * mno-sep-data: Blackfin Options. (line 112) |
| * mno-serialize-volatile: Xtensa Options. (line 35) |
| * mno-short: M680x0 Options. (line 225) |
| * mno-side-effects: CRIS Options. (line 46) |
| * mno-sim: RX Options. (line 70) |
| * 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 269) |
| * mno-soft-float: DEC Alpha Options. (line 10) |
| * mno-space-regs: HPPA Options. (line 45) |
| * mno-spe: RS/6000 and PowerPC Options. |
| (line 229) |
| * mno-specld-anomaly: Blackfin Options. (line 52) |
| * mno-split-addresses: MIPS Options. (line 411) |
| * mno-sse: i386 and x86-64 Options. |
| (line 477) |
| * mno-stack-align: CRIS Options. (line 55) |
| * mno-stack-bias: SPARC Options. (line 213) |
| * mno-strict-align <1>: RS/6000 and PowerPC Options. |
| (line 456) |
| * mno-strict-align: M680x0 Options. (line 286) |
| * mno-string: RS/6000 and PowerPC Options. |
| (line 391) |
| * mno-sum-in-toc: RS/6000 and PowerPC Options. |
| (line 277) |
| * mno-sym32: MIPS Options. (line 308) |
| * mno-target-align: Xtensa Options. (line 59) |
| * mno-text-section-literals: Xtensa Options. (line 47) |
| * mno-tls-markers: RS/6000 and PowerPC Options. |
| (line 750) |
| * mno-toc: RS/6000 and PowerPC Options. |
| (line 481) |
| * 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 381) |
| * mno-update: RS/6000 and PowerPC Options. |
| (line 402) |
| * mno-v8plus: SPARC Options. (line 156) |
| * mno-vis: SPARC Options. (line 163) |
| * mno-vliw-branch: FRV Options. (line 170) |
| * mno-volatile-asm-stop: IA-64 Options. (line 32) |
| * mno-vrsave: RS/6000 and PowerPC Options. |
| (line 199) |
| * mno-vsx: RS/6000 and PowerPC Options. |
| (line 243) |
| * mno-wide-bitfields: MCore Options. (line 23) |
| * mno-xgot <1>: MIPS Options. (line 191) |
| * mno-xgot: M680x0 Options. (line 318) |
| * mno-xl-compat: RS/6000 and PowerPC Options. |
| (line 312) |
| * mno-zero-extend: MMIX Options. (line 27) |
| * mnobitfield: M680x0 Options. (line 230) |
| * mnoliw: MN10300 Options. (line 60) |
| * mnomacsave: SH Options. (line 112) |
| * mnominmax: M68hc1x Options. (line 31) |
| * mnop-fun-dllimport: i386 and x86-64 Windows Options. |
| (line 22) |
| * mold-mnemonics: RS/6000 and PowerPC Options. |
| (line 104) |
| * momit-leaf-frame-pointer <1>: i386 and x86-64 Options. |
| (line 650) |
| * momit-leaf-frame-pointer: Blackfin Options. (line 40) |
| * 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 138) |
| * mpaired: RS/6000 and PowerPC Options. |
| (line 234) |
| * mpaired-single: MIPS Options. (line 273) |
| * mpc32: i386 and x86-64 Options. |
| (line 372) |
| * mpc64: i386 and x86-64 Options. |
| (line 372) |
| * mpc80: i386 and x86-64 Options. |
| (line 372) |
| * mpcrel: M680x0 Options. (line 278) |
| * mpdebug: CRIS Options. (line 35) |
| * mpe: RS/6000 and PowerPC Options. |
| (line 332) |
| * mpe-aligned-commons: i386 and x86-64 Windows Options. |
| (line 53) |
| * mpic-register: ARM Options. (line 198) |
| * mplt: MIPS Options. (line 181) |
| * mpoke-function-name: ARM Options. (line 212) |
| * mpopcntb: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpopcntd: RS/6000 and PowerPC Options. |
| (line 33) |
| * mportable-runtime: HPPA Options. (line 71) |
| * mpower: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpower2: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpowerpc: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpowerpc-gfxopt: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpowerpc-gpopt: RS/6000 and PowerPC Options. |
| (line 33) |
| * mpowerpc64: RS/6000 and PowerPC Options. |
| (line 33) |
| * mprefergot: SH Options. (line 145) |
| * mpreferred-stack-boundary: i386 and x86-64 Options. |
| (line 402) |
| * mprioritize-restricted-insns: RS/6000 and PowerPC Options. |
| (line 510) |
| * mprolog-function: V850 Options. (line 23) |
| * mprologue-epilogue: CRIS Options. (line 71) |
| * mprototype: RS/6000 and PowerPC Options. |
| (line 605) |
| * mpt-fixed: SH Options. (line 238) |
| * mpush-args <1>: i386 and x86-64 Options. |
| (line 602) |
| * mpush-args: CRX Options. (line 13) |
| * MQ: Preprocessor Options. |
| (line 253) |
| * mr10k-cache-barrier: MIPS Options. (line 540) |
| * mrecip <1>: RS/6000 and PowerPC Options. |
| (line 762) |
| * mrecip: i386 and x86-64 Options. |
| (line 554) |
| * mrecip-precision: RS/6000 and PowerPC Options. |
| (line 798) |
| * mrecip=opt: RS/6000 and PowerPC Options. |
| (line 775) |
| * mregister-names: IA-64 Options. (line 37) |
| * mregnames: RS/6000 and PowerPC Options. |
| (line 711) |
| * mregparm: i386 and x86-64 Options. |
| (line 339) |
| * mrelax <1>: SH Options. (line 86) |
| * mrelax <2>: RX Options. (line 94) |
| * mrelax <3>: MN10300 Options. (line 47) |
| * mrelax: H8/300 Options. (line 9) |
| * mrelax-immediate: MCore Options. (line 19) |
| * mrelax-pic-calls: MIPS Options. (line 665) |
| * mrelocatable: RS/6000 and PowerPC Options. |
| (line 461) |
| * mrelocatable-lib: RS/6000 and PowerPC Options. |
| (line 472) |
| * mrepeat: MeP Options. (line 96) |
| * mreturn-pointer-on-d0: MN10300 Options. (line 37) |
| * mrodata: ARC Options. (line 30) |
| * mrtd <1>: Function Attributes. |
| (line 177) |
| * mrtd <2>: M680x0 Options. (line 239) |
| * mrtd: i386 and x86-64 Options. |
| (line 315) |
| * mrtp: VxWorks Options. (line 11) |
| * ms <1>: MeP Options. (line 100) |
| * ms: H8/300 Options. (line 17) |
| * ms2600: H8/300 Options. (line 24) |
| * msafe-dma: SPU Options. (line 17) |
| * msafe-hints: SPU Options. (line 107) |
| * msahf: i386 and x86-64 Options. |
| (line 534) |
| * msatur: MeP Options. (line 105) |
| * msave-acc-in-interrupts: RX Options. (line 108) |
| * mscc: FRV Options. (line 140) |
| * msched-ar-data-spec: IA-64 Options. (line 135) |
| * msched-ar-in-data-spec: IA-64 Options. (line 156) |
| * msched-br-data-spec: IA-64 Options. (line 128) |
| * msched-br-in-data-spec: IA-64 Options. (line 149) |
| * msched-control-spec: IA-64 Options. (line 142) |
| * msched-costly-dep: RS/6000 and PowerPC Options. |
| (line 517) |
| * msched-count-spec-in-critical-path: IA-64 Options. (line 183) |
| * msched-fp-mem-deps-zero-cost: IA-64 Options. (line 200) |
| * msched-in-control-spec: IA-64 Options. (line 163) |
| * msched-max-memory-insns: IA-64 Options. (line 209) |
| * msched-max-memory-insns-hard-limit: IA-64 Options. (line 215) |
| * msched-prefer-non-control-spec-insns: IA-64 Options. (line 176) |
| * msched-prefer-non-data-spec-insns: IA-64 Options. (line 169) |
| * msched-spec-ldc: IA-64 Options. (line 189) |
| * msched-stop-bits-after-every-cycle: IA-64 Options. (line 196) |
| * 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 679) |
| * msdata: IA-64 Options. (line 42) |
| * msdata=data: RS/6000 and PowerPC Options. |
| (line 684) |
| * msdata=default: RS/6000 and PowerPC Options. |
| (line 679) |
| * msdata=eabi: RS/6000 and PowerPC Options. |
| (line 659) |
| * msdata=none <1>: RS/6000 and PowerPC Options. |
| (line 692) |
| * msdata=none: M32R/D Options. (line 40) |
| * msdata=sdata: M32R/D Options. (line 49) |
| * msdata=sysv: RS/6000 and PowerPC Options. |
| (line 670) |
| * msdata=use: M32R/D Options. (line 53) |
| * msdram <1>: MeP Options. (line 110) |
| * msdram: Blackfin Options. (line 163) |
| * msecure-plt: RS/6000 and PowerPC Options. |
| (line 209) |
| * msel-sched-dont-check-control-spec: IA-64 Options. (line 205) |
| * msep-data: Blackfin Options. (line 106) |
| * mserialize-volatile: Xtensa Options. (line 35) |
| * mshared-library-id: Blackfin Options. (line 99) |
| * mshort <1>: M68hc1x Options. (line 40) |
| * mshort: M680x0 Options. (line 219) |
| * msign-extend-enabled: LM32 Options. (line 18) |
| * msim <1>: Xstormy16 Options. (line 9) |
| * msim <2>: RX Options. (line 70) |
| * msim <3>: RS/6000 and PowerPC Options. |
| (line 615) |
| * msim <4>: MeP Options. (line 114) |
| * msim <5>: M32C Options. (line 13) |
| * msim: Blackfin Options. (line 33) |
| * msimnovec: MeP Options. (line 117) |
| * msimple-fpu: RS/6000 and PowerPC Options. |
| (line 365) |
| * msingle-exit: MMIX Options. (line 66) |
| * msingle-float <1>: RS/6000 and PowerPC Options. |
| (line 361) |
| * msingle-float: MIPS Options. (line 233) |
| * msingle-pic-base <1>: RS/6000 and PowerPC Options. |
| (line 504) |
| * msingle-pic-base: ARM Options. (line 192) |
| * msio: HPPA Options. (line 105) |
| * mslow-bytes: MCore Options. (line 35) |
| * msmall-data: DEC Alpha Options. (line 195) |
| * msmall-data-limit: RX Options. (line 47) |
| * msmall-divides: MicroBlaze Options. (line 38) |
| * 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 269) |
| * 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 355) |
| * msoft-float <4>: PDP-11 Options. (line 13) |
| * msoft-float <5>: MIPS Options. (line 229) |
| * msoft-float <6>: MicroBlaze Options. (line 7) |
| * msoft-float <7>: M680x0 Options. (line 202) |
| * msoft-float <8>: i386 and x86-64 Options. |
| (line 234) |
| * msoft-float <9>: HPPA Options. (line 91) |
| * msoft-float <10>: FRV Options. (line 22) |
| * msoft-float <11>: DEC Alpha Options. (line 10) |
| * msoft-float: ARM Options. (line 60) |
| * msoft-quad-float: SPARC Options. (line 45) |
| * msoft-reg-count: M68hc1x Options. (line 43) |
| * mspace <1>: V850 Options. (line 30) |
| * mspace: SH Options. (line 142) |
| * mspe: RS/6000 and PowerPC Options. |
| (line 229) |
| * mspecld-anomaly: Blackfin Options. (line 47) |
| * msplit-addresses: MIPS Options. (line 411) |
| * msse: i386 and x86-64 Options. |
| (line 477) |
| * msse2avx: i386 and x86-64 Options. |
| (line 668) |
| * msseregparm: i386 and x86-64 Options. |
| (line 350) |
| * mstack-align: CRIS Options. (line 55) |
| * mstack-bias: SPARC Options. (line 213) |
| * mstack-check-l1: Blackfin Options. (line 73) |
| * 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 393) |
| * mstdmain: SPU Options. (line 40) |
| * mstrict-align <1>: RS/6000 and PowerPC Options. |
| (line 456) |
| * mstrict-align: M680x0 Options. (line 286) |
| * mstring: RS/6000 and PowerPC Options. |
| (line 391) |
| * mstringop-strategy=ALG: i386 and x86-64 Options. |
| (line 642) |
| * mstructure-size-boundary: ARM Options. (line 147) |
| * msvr4-struct-return: RS/6000 and PowerPC Options. |
| (line 579) |
| * msym32: MIPS Options. (line 308) |
| * msynci: MIPS Options. (line 650) |
| * MT: Preprocessor Options. |
| (line 239) |
| * mtarget-align: Xtensa Options. (line 59) |
| * mtda: V850 Options. (line 34) |
| * mtext: ARC Options. (line 30) |
| * mtext-section-literals: Xtensa Options. (line 47) |
| * mtf: MeP Options. (line 121) |
| * mthread: i386 and x86-64 Windows Options. |
| (line 26) |
| * mthreads: i386 and x86-64 Options. |
| (line 617) |
| * mthumb: ARM Options. (line 233) |
| * mthumb-interwork: ARM Options. (line 25) |
| * mtiny-stack: AVR Options. (line 40) |
| * mtiny=: MeP Options. (line 125) |
| * mtls: FRV Options. (line 75) |
| * mTLS: FRV Options. (line 72) |
| * mtls-direct-seg-refs: i386 and x86-64 Options. |
| (line 658) |
| * mtls-markers: RS/6000 and PowerPC Options. |
| (line 750) |
| * mtls-size: IA-64 Options. (line 112) |
| * mtoc: RS/6000 and PowerPC Options. |
| (line 481) |
| * mtomcat-stats: FRV Options. (line 209) |
| * mtoplevel-symbols: MMIX Options. (line 40) |
| * mtp: ARM Options. (line 270) |
| * mtpcs-frame: ARM Options. (line 243) |
| * mtpcs-leaf-frame: ARM Options. (line 249) |
| * mtpf-trace: S/390 and zSeries Options. |
| (line 131) |
| * mtrap-precision: DEC Alpha Options. (line 109) |
| * mtune <1>: SPARC Options. (line 143) |
| * mtune <2>: S/390 and zSeries Options. |
| (line 124) |
| * mtune <3>: RS/6000 and PowerPC Options. |
| (line 168) |
| * mtune <4>: MN10300 Options. (line 31) |
| * mtune <5>: MIPS Options. (line 62) |
| * mtune <6>: M680x0 Options. (line 69) |
| * mtune <7>: IA-64 Options. (line 116) |
| * mtune <8>: i386 and x86-64 Options. |
| (line 10) |
| * mtune <9>: DEC Alpha Options. (line 267) |
| * mtune <10>: CRIS Options. (line 16) |
| * mtune: ARM Options. (line 98) |
| * muclibc: GNU/Linux Options. (line 13) |
| * muls: Score Options. (line 18) |
| * multcost=NUMBER: SH Options. (line 155) |
| * multi_module: Darwin Options. (line 199) |
| * multilib-library-pic: FRV Options. (line 89) |
| * multiply-enabled: LM32 Options. (line 15) |
| * multiply_defined: Darwin Options. (line 199) |
| * multiply_defined_unused: Darwin Options. (line 199) |
| * munaligned-doubles: SPARC Options. (line 59) |
| * municode: i386 and x86-64 Windows Options. |
| (line 30) |
| * muninit-const-in-rodata: MIPS Options. (line 381) |
| * munix: VAX Options. (line 9) |
| * munix-asm: PDP-11 Options. (line 68) |
| * munsafe-dma: SPU Options. (line 17) |
| * mupdate: RS/6000 and PowerPC Options. |
| (line 402) |
| * muser-enabled: LM32 Options. (line 21) |
| * musermode: SH Options. (line 150) |
| * mv850: V850 Options. (line 49) |
| * mv850e: V850 Options. (line 81) |
| * mv850e1: V850 Options. (line 73) |
| * mv850e2: V850 Options. (line 69) |
| * mv850e2v3: V850 Options. (line 64) |
| * mv850es: V850 Options. (line 77) |
| * mv8plus: SPARC Options. (line 156) |
| * mveclibabi <1>: RS/6000 and PowerPC Options. |
| (line 807) |
| * mveclibabi: i386 and x86-64 Options. |
| (line 571) |
| * mvect8-ret-in-mem: i386 and x86-64 Options. |
| (line 360) |
| * mvis: SPARC Options. (line 163) |
| * mvliw-branch: FRV Options. (line 164) |
| * mvms-return-codes <1>: IA-64/VMS Options. (line 9) |
| * mvms-return-codes: DEC Alpha/VMS Options. |
| (line 9) |
| * mvolatile-asm-stop: IA-64 Options. (line 32) |
| * mvr4130-align: MIPS Options. (line 639) |
| * mvrsave: RS/6000 and PowerPC Options. |
| (line 199) |
| * mvsx: RS/6000 and PowerPC Options. |
| (line 243) |
| * mvxworks: RS/6000 and PowerPC Options. |
| (line 636) |
| * mvzeroupper: i386 and x86-64 Options. |
| (line 520) |
| * mwarn-cell-microcode: RS/6000 and PowerPC Options. |
| (line 205) |
| * 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 35) |
| * mwindows: i386 and x86-64 Windows Options. |
| (line 41) |
| * mword-relocations: ARM Options. (line 278) |
| * mwords-little-endian: ARM Options. (line 71) |
| * mxgot <1>: MIPS Options. (line 191) |
| * mxgot: M680x0 Options. (line 318) |
| * mxilinx-fpu: RS/6000 and PowerPC Options. |
| (line 375) |
| * mxl-barrel-shift: MicroBlaze Options. (line 32) |
| * mxl-compat: RS/6000 and PowerPC Options. |
| (line 312) |
| * mxl-float-convert: MicroBlaze Options. (line 50) |
| * mxl-float-sqrt: MicroBlaze Options. (line 53) |
| * mxl-gp-opt: MicroBlaze Options. (line 44) |
| * mxl-multiply-high: MicroBlaze Options. (line 47) |
| * mxl-pattern-compare: MicroBlaze Options. (line 35) |
| * mxl-soft-div: MicroBlaze Options. (line 29) |
| * mxl-soft-mul: MicroBlaze Options. (line 26) |
| * mxl-stack-check: MicroBlaze Options. (line 41) |
| * myellowknife: RS/6000 and PowerPC Options. |
| (line 631) |
| * mzarch: S/390 and zSeries Options. |
| (line 95) |
| * mzda: V850 Options. (line 45) |
| * mzero-extend: MMIX Options. (line 27) |
| * no-canonical-prefixes: Overall Options. (line 343) |
| * no-integrated-cpp: C Dialect Options. (line 272) |
| * no_dead_strip_inits_and_terms: Darwin Options. (line 199) |
| * noall_load: Darwin Options. (line 199) |
| * nocpp: MIPS Options. (line 477) |
| * nodefaultlibs: Link Options. (line 62) |
| * nofixprebinding: Darwin Options. (line 199) |
| * nofpu: RX Options. (line 17) |
| * 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 385) |
| * nostdinc++ <1>: Preprocessor Options. |
| (line 390) |
| * nostdinc++: C++ Dialect Options. |
| (line 322) |
| * nostdlib: Link Options. (line 73) |
| * o: Preprocessor Options. |
| (line 75) |
| * O: Optimize Options. (line 39) |
| * o: Overall Options. (line 192) |
| * O0: Optimize Options. (line 126) |
| * O1: Optimize Options. (line 39) |
| * O2: Optimize Options. (line 82) |
| * O3: Optimize Options. (line 119) |
| * Ofast: Optimize Options. (line 140) |
| * Os: Optimize Options. (line 130) |
| * P: Preprocessor Options. |
| (line 603) |
| * p: Debugging Options. (line 295) |
| * pagezero_size: Darwin Options. (line 199) |
| * param: Optimize Options. (line 2264) |
| * pass-exit-codes: Overall Options. (line 150) |
| * pedantic <1>: Warnings and Errors. |
| (line 25) |
| * pedantic <2>: Alternate Keywords. (line 30) |
| * pedantic <3>: C Extensions. (line 6) |
| * pedantic <4>: Preprocessor Options. |
| (line 163) |
| * pedantic <5>: Warning Options. (line 72) |
| * 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 114) |
| * pedantic-errors: Standards. (line 16) |
| * pg: Debugging Options. (line 301) |
| * pie: Link Options. (line 95) |
| * pipe: Overall Options. (line 215) |
| * prebind: Darwin Options. (line 199) |
| * prebind_all_twolevel_modules: Darwin Options. (line 199) |
| * print-file-name: Debugging Options. (line 1140) |
| * print-libgcc-file-name: Debugging Options. (line 1170) |
| * print-multi-directory: Debugging Options. (line 1146) |
| * print-multi-lib: Debugging Options. (line 1151) |
| * print-multi-os-directory: Debugging Options. (line 1158) |
| * print-objc-runtime-info: Objective-C and Objective-C++ Dialect Options. |
| (line 203) |
| * print-prog-name: Debugging Options. (line 1167) |
| * print-search-dirs: Debugging Options. (line 1178) |
| * print-sysroot: Debugging Options. (line 1191) |
| * print-sysroot-headers-suffix: Debugging Options. (line 1198) |
| * private_bundle: Darwin Options. (line 199) |
| * pthread <1>: Solaris 2 Options. (line 37) |
| * pthread: RS/6000 and PowerPC Options. |
| (line 757) |
| * pthreads: Solaris 2 Options. (line 31) |
| * Q: Debugging Options. (line 307) |
| * Qn: System V Options. (line 18) |
| * Qy: System V Options. (line 14) |
| * rdynamic: Link Options. (line 101) |
| * read_only_relocs: Darwin Options. (line 199) |
| * remap: Preprocessor Options. |
| (line 651) |
| * s: Link Options. (line 108) |
| * S <1>: Link Options. (line 20) |
| * S: Overall Options. (line 175) |
| * save-temps: Debugging Options. (line 1048) |
| * save-temps=obj: Debugging Options. (line 1074) |
| * 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 117) |
| * shared-libgcc: Link Options. (line 125) |
| * sim: CRIS Options. (line 95) |
| * sim2: CRIS Options. (line 101) |
| * single_module: Darwin Options. (line 199) |
| * specs: Directory Options. (line 89) |
| * static <1>: HPPA Options. (line 192) |
| * static <2>: Darwin Options. (line 199) |
| * static: Link Options. (line 112) |
| * static-libgcc: Link Options. (line 125) |
| * 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 172) |
| * sysroot: Directory Options. (line 97) |
| * T: Link Options. (line 178) |
| * target-help <1>: Preprocessor Options. |
| (line 656) |
| * target-help: Overall Options. (line 230) |
| * threads <1>: Solaris 2 Options. (line 25) |
| * threads: HPPA Options. (line 205) |
| * time: Debugging Options. (line 1089) |
| * tno-android-cc: GNU/Linux Options. (line 31) |
| * tno-android-ld: GNU/Linux Options. (line 35) |
| * traditional <1>: Incompatibilities. (line 6) |
| * traditional: C Dialect Options. (line 284) |
| * traditional-cpp <1>: Preprocessor Options. |
| (line 634) |
| * traditional-cpp: C Dialect Options. (line 284) |
| * trigraphs <1>: Preprocessor Options. |
| (line 638) |
| * trigraphs: C Dialect Options. (line 268) |
| * twolevel_namespace: Darwin Options. (line 199) |
| * u: Link Options. (line 211) |
| * 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 <1>: Preprocessor Options. |
| (line 660) |
| * v: Overall Options. (line 203) |
| * version <1>: Preprocessor Options. |
| (line 673) |
| * version: Overall Options. (line 351) |
| * W: Incompatibilities. (line 64) |
| * w: Preprocessor Options. |
| (line 159) |
| * W: Warning Options. (line 168) |
| * w: Warning Options. (line 25) |
| * Wa: Assembler Options. (line 9) |
| * Wabi: C++ Dialect Options. |
| (line 336) |
| * Waddress: Warning Options. (line 1214) |
| * Waggregate-return: Warning Options. (line 1232) |
| * Wall <1>: Standard Libraries. (line 6) |
| * Wall <2>: Preprocessor Options. |
| (line 81) |
| * Wall: Warning Options. (line 118) |
| * Warray-bounds: Warning Options. (line 877) |
| * Wassign-intercept: Objective-C and Objective-C++ Dialect Options. |
| (line 157) |
| * Wattributes: Warning Options. (line 1237) |
| * Wbad-function-cast: Warning Options. (line 1100) |
| * Wbuiltin-macro-redefined: Warning Options. (line 1243) |
| * Wcast-align: Warning Options. (line 1131) |
| * Wcast-qual: Warning Options. (line 1115) |
| * Wchar-subscripts: Warning Options. (line 207) |
| * Wclobbered: Warning Options. (line 1151) |
| * Wcomment <1>: Preprocessor Options. |
| (line 89) |
| * Wcomment: Warning Options. (line 212) |
| * Wcomments: Preprocessor Options. |
| (line 89) |
| * Wconversion: Warning Options. (line 1155) |
| * Wconversion-null: Warning Options. (line 1173) |
| * Wcoverage-mismatch: Language Independent Options. |
| (line 42) |
| * Wctor-dtor-privacy: C++ Dialect Options. |
| (line 446) |
| * Wdeclaration-after-statement: Warning Options. (line 1009) |
| * Wdeprecated: Warning Options. (line 1372) |
| * Wdeprecated-declarations: Warning Options. (line 1376) |
| * Wdisabled-optimization: Warning Options. (line 1511) |
| * Wdiv-by-zero: Warning Options. (line 882) |
| * Wdouble-promotion: Warning Options. (line 222) |
| * weak_reference_mismatches: Darwin Options. (line 199) |
| * Weffc++: C++ Dialect Options. |
| (line 479) |
| * Wempty-body: Warning Options. (line 1181) |
| * Wendif-labels <1>: Preprocessor Options. |
| (line 136) |
| * Wendif-labels: Warning Options. (line 1019) |
| * Wenum-compare: Warning Options. (line 1185) |
| * Werror <1>: Preprocessor Options. |
| (line 149) |
| * Werror: Warning Options. (line 28) |
| * Werror=: Warning Options. (line 31) |
| * Wextra: Warning Options. (line 168) |
| * Wfatal-errors: Warning Options. (line 48) |
| * Wfloat-equal: Warning Options. (line 909) |
| * Wformat <1>: Function Attributes. |
| (line 420) |
| * Wformat: Warning Options. (line 240) |
| * Wformat-contains-nul: Warning Options. (line 279) |
| * Wformat-extra-args: Warning Options. (line 283) |
| * Wformat-nonliteral <1>: Function Attributes. |
| (line 485) |
| * Wformat-nonliteral: Warning Options. (line 301) |
| * Wformat-security: Warning Options. (line 306) |
| * Wformat-y2k: Warning Options. (line 275) |
| * Wformat-zero-length: Warning Options. (line 297) |
| * Wformat=2: Warning Options. (line 317) |
| * Wframe-larger-than: Warning Options. (line 1065) |
| * whatsloaded: Darwin Options. (line 199) |
| * whyload: Darwin Options. (line 199) |
| * Wignored-qualifiers: Warning Options. (line 356) |
| * Wimplicit: Warning Options. (line 352) |
| * Wimplicit-function-declaration: Warning Options. (line 346) |
| * Wimplicit-int: Warning Options. (line 342) |
| * Winit-self: Warning Options. (line 329) |
| * Winline <1>: Inline. (line 63) |
| * Winline: Warning Options. (line 1442) |
| * Wint-to-pointer-cast: Warning Options. (line 1469) |
| * Winvalid-offsetof: Warning Options. (line 1455) |
| * Winvalid-pch: Warning Options. (line 1486) |
| * Wjump-misses-init: Warning Options. (line 1190) |
| * Wl: Link Options. (line 203) |
| * Wlarger-than-LEN: Warning Options. (line 1062) |
| * Wlarger-than=LEN: Warning Options. (line 1062) |
| * Wlogical-op: Warning Options. (line 1227) |
| * Wlong-long: Warning Options. (line 1490) |
| * Wmain: Warning Options. (line 367) |
| * Wmaybe-uninitialized: Warning Options. (line 711) |
| * Wmissing-braces: Warning Options. (line 374) |
| * Wmissing-declarations: Warning Options. (line 1278) |
| * Wmissing-field-initializers: Warning Options. (line 1286) |
| * Wmissing-format-attribute: Warning Options. (line 1304) |
| * Wmissing-include-dirs: Warning Options. (line 384) |
| * Wmissing-parameter-type: Warning Options. (line 1264) |
| * Wmissing-prototypes: Warning Options. (line 1272) |
| * Wmultichar: Warning Options. (line 1323) |
| * Wnested-externs: Warning Options. (line 1439) |
| * Wno-abi: C++ Dialect Options. |
| (line 336) |
| * Wno-address: Warning Options. (line 1214) |
| * Wno-aggregate-return: Warning Options. (line 1232) |
| * Wno-all: Warning Options. (line 118) |
| * Wno-array-bounds: Warning Options. (line 877) |
| * Wno-assign-intercept: Objective-C and Objective-C++ Dialect Options. |
| (line 157) |
| * Wno-attributes: Warning Options. (line 1237) |
| * Wno-bad-function-cast: Warning Options. (line 1100) |
| * Wno-builtin-macro-redefined: Warning Options. (line 1243) |
| * Wno-cast-align: Warning Options. (line 1131) |
| * Wno-cast-qual: Warning Options. (line 1115) |
| * Wno-char-subscripts: Warning Options. (line 207) |
| * Wno-clobbered: Warning Options. (line 1151) |
| * Wno-comment: Warning Options. (line 212) |
| * Wno-conversion: Warning Options. (line 1155) |
| * Wno-conversion-null: Warning Options. (line 1173) |
| * Wno-ctor-dtor-privacy: C++ Dialect Options. |
| (line 446) |
| * Wno-declaration-after-statement: Warning Options. (line 1009) |
| * Wno-deprecated: Warning Options. (line 1372) |
| * Wno-deprecated-declarations: Warning Options. (line 1376) |
| * Wno-disabled-optimization: Warning Options. (line 1511) |
| * Wno-div-by-zero: Warning Options. (line 882) |
| * Wno-double-promotion: Warning Options. (line 222) |
| * Wno-effc++: C++ Dialect Options. |
| (line 479) |
| * Wno-empty-body: Warning Options. (line 1181) |
| * Wno-endif-labels: Warning Options. (line 1019) |
| * Wno-enum-compare: Warning Options. (line 1185) |
| * Wno-error: Warning Options. (line 28) |
| * Wno-error=: Warning Options. (line 31) |
| * Wno-extra: Warning Options. (line 168) |
| * Wno-fatal-errors: Warning Options. (line 48) |
| * Wno-float-equal: Warning Options. (line 909) |
| * Wno-format: Warning Options. (line 240) |
| * Wno-format-contains-nul: Warning Options. (line 279) |
| * Wno-format-extra-args: Warning Options. (line 283) |
| * Wno-format-nonliteral: Warning Options. (line 301) |
| * Wno-format-security: Warning Options. (line 306) |
| * Wno-format-y2k: Warning Options. (line 275) |
| * Wno-format-zero-length: Warning Options. (line 297) |
| * Wno-format=2: Warning Options. (line 317) |
| * Wno-ignored-qualifiers: Warning Options. (line 356) |
| * Wno-implicit: Warning Options. (line 352) |
| * Wno-implicit-function-declaration: Warning Options. (line 346) |
| * Wno-implicit-int: Warning Options. (line 342) |
| * Wno-init-self: Warning Options. (line 329) |
| * Wno-inline: Warning Options. (line 1442) |
| * Wno-int-to-pointer-cast: Warning Options. (line 1469) |
| * Wno-invalid-offsetof: Warning Options. (line 1455) |
| * Wno-invalid-pch: Warning Options. (line 1486) |
| * Wno-jump-misses-init: Warning Options. (line 1190) |
| * Wno-logical-op: Warning Options. (line 1227) |
| * Wno-long-long: Warning Options. (line 1490) |
| * Wno-main: Warning Options. (line 367) |
| * Wno-maybe-uninitialized: Warning Options. (line 711) |
| * Wno-missing-braces: Warning Options. (line 374) |
| * Wno-missing-declarations: Warning Options. (line 1278) |
| * Wno-missing-field-initializers: Warning Options. (line 1286) |
| * Wno-missing-format-attribute: Warning Options. (line 1304) |
| * Wno-missing-include-dirs: Warning Options. (line 384) |
| * Wno-missing-parameter-type: Warning Options. (line 1264) |
| * Wno-missing-prototypes: Warning Options. (line 1272) |
| * Wno-mudflap: Warning Options. (line 1531) |
| * Wno-multichar: Warning Options. (line 1323) |
| * Wno-nested-externs: Warning Options. (line 1439) |
| * Wno-noexcept: C++ Dialect Options. |
| (line 451) |
| * Wno-non-template-friend: C++ Dialect Options. |
| (line 516) |
| * Wno-non-virtual-dtor: C++ Dialect Options. |
| (line 457) |
| * Wno-nonnull: Warning Options. (line 322) |
| * Wno-old-style-cast: C++ Dialect Options. |
| (line 532) |
| * Wno-old-style-declaration: Warning Options. (line 1254) |
| * Wno-old-style-definition: Warning Options. (line 1260) |
| * Wno-overflow: Warning Options. (line 1382) |
| * Wno-overlength-strings: Warning Options. (line 1535) |
| * Wno-overloaded-virtual: C++ Dialect Options. |
| (line 538) |
| * Wno-override-init: Warning Options. (line 1385) |
| * Wno-packed: Warning Options. (line 1393) |
| * Wno-packed-bitfield-compat: Warning Options. (line 1410) |
| * Wno-padded: Warning Options. (line 1427) |
| * Wno-parentheses: Warning Options. (line 387) |
| * Wno-pedantic-ms-format: Warning Options. (line 1080) |
| * Wno-pmf-conversions <1>: Bound member functions. |
| (line 35) |
| * Wno-pmf-conversions: C++ Dialect Options. |
| (line 557) |
| * Wno-pointer-arith: Warning Options. (line 1086) |
| * Wno-pointer-sign: Warning Options. (line 1520) |
| * Wno-pointer-to-int-cast: Warning Options. (line 1482) |
| * Wno-pragmas: Warning Options. (line 762) |
| * Wno-protocol: Objective-C and Objective-C++ Dialect Options. |
| (line 161) |
| * Wno-real-conversion: Warning Options. (line 1177) |
| * Wno-redundant-decls: Warning Options. (line 1434) |
| * Wno-reorder: C++ Dialect Options. |
| (line 463) |
| * Wno-return-type: Warning Options. (line 527) |
| * Wno-ripa-opt-mismatch: Warning Options. (line 542) |
| * Wno-selector: Objective-C and Objective-C++ Dialect Options. |
| (line 171) |
| * Wno-self-assign: Warning Options. (line 483) |
| * Wno-self-assign-non-pod: Warning Options. (line 506) |
| * Wno-sequence-point: Warning Options. (line 437) |
| * Wno-shadow: Warning Options. (line 1023) |
| * Wno-shadow-compatible-local: Warning Options. (line 1034) |
| * Wno-shadow-local: Warning Options. (line 1030) |
| * Wno-sign-compare: Warning Options. (line 1201) |
| * Wno-sign-conversion: Warning Options. (line 1208) |
| * Wno-sign-promo: C++ Dialect Options. |
| (line 561) |
| * Wno-stack-protector: Warning Options. (line 1526) |
| * Wno-strict-aliasing: Warning Options. (line 767) |
| * Wno-strict-aliasing=n: Warning Options. (line 775) |
| * Wno-strict-null-sentinel: C++ Dialect Options. |
| (line 509) |
| * Wno-strict-overflow: Warning Options. (line 808) |
| * Wno-strict-prototypes: Warning Options. (line 1248) |
| * Wno-strict-selector-match: Objective-C and Objective-C++ Dialect Options. |
| (line 183) |
| * Wno-suggest-attribute=: Warning Options. (line 859) |
| * Wno-suggest-attribute=const: Warning Options. (line 865) |
| * Wno-suggest-attribute=noreturn: Warning Options. (line 865) |
| * Wno-suggest-attribute=pure: Warning Options. (line 865) |
| * Wno-switch: Warning Options. (line 550) |
| * Wno-switch-default: Warning Options. (line 558) |
| * Wno-switch-enum: Warning Options. (line 561) |
| * Wno-sync-nand: Warning Options. (line 570) |
| * Wno-system-headers: Warning Options. (line 887) |
| * Wno-thread-safety: Warning Options. (line 575) |
| * Wno-traditional: Warning Options. (line 924) |
| * Wno-traditional-conversion: Warning Options. (line 1001) |
| * Wno-trampolines: Warning Options. (line 898) |
| * Wno-trigraphs: Warning Options. (line 611) |
| * Wno-type-limits: Warning Options. (line 1093) |
| * Wno-undeclared-selector: Objective-C and Objective-C++ Dialect Options. |
| (line 191) |
| * Wno-undef: Warning Options. (line 1016) |
| * Wno-uninitialized: Warning Options. (line 688) |
| * Wno-unknown-pragmas: Warning Options. (line 755) |
| * Wno-unsafe-loop-optimizations: Warning Options. (line 1074) |
| * Wno-unused: Warning Options. (line 681) |
| * Wno-unused-but-set-parameter: Warning Options. (line 616) |
| * Wno-unused-but-set-variable: Warning Options. (line 625) |
| * Wno-unused-function: Warning Options. (line 635) |
| * Wno-unused-label: Warning Options. (line 640) |
| * Wno-unused-parameter: Warning Options. (line 647) |
| * Wno-unused-result: Warning Options. (line 654) |
| * Wno-unused-value: Warning Options. (line 671) |
| * Wno-unused-variable: Warning Options. (line 659) |
| * Wno-variadic-macros: Warning Options. (line 1495) |
| * Wno-vla: Warning Options. (line 1501) |
| * Wno-volatile-register-var: Warning Options. (line 1505) |
| * Wno-write-strings: Warning Options. (line 1137) |
| * Wnoexcept: C++ Dialect Options. |
| (line 451) |
| * Wnon-template-friend: C++ Dialect Options. |
| (line 516) |
| * Wnon-virtual-dtor: C++ Dialect Options. |
| (line 457) |
| * Wnonnull: Warning Options. (line 322) |
| * Wnormalized=: Warning Options. (line 1329) |
| * Wold-style-cast: C++ Dialect Options. |
| (line 532) |
| * Wold-style-declaration: Warning Options. (line 1254) |
| * Wold-style-definition: Warning Options. (line 1260) |
| * Woverflow: Warning Options. (line 1382) |
| * Woverlength-strings: Warning Options. (line 1535) |
| * Woverloaded-virtual: C++ Dialect Options. |
| (line 538) |
| * Woverride-init: Warning Options. (line 1385) |
| * Wp: Preprocessor Options. |
| (line 14) |
| * Wpacked: Warning Options. (line 1393) |
| * Wpacked-bitfield-compat: Warning Options. (line 1410) |
| * Wpadded: Warning Options. (line 1427) |
| * Wparentheses: Warning Options. (line 387) |
| * Wpedantic-ms-format: Warning Options. (line 1080) |
| * Wpmf-conversions: C++ Dialect Options. |
| (line 557) |
| * Wpointer-arith <1>: Pointer Arith. (line 13) |
| * Wpointer-arith: Warning Options. (line 1086) |
| * Wpointer-sign: Warning Options. (line 1520) |
| * Wpointer-to-int-cast: Warning Options. (line 1482) |
| * Wpragmas: Warning Options. (line 762) |
| * Wprotocol: Objective-C and Objective-C++ Dialect Options. |
| (line 161) |
| * wrapper: Overall Options. (line 354) |
| * Wreal-conversion: Warning Options. (line 1177) |
| * Wredundant-decls: Warning Options. (line 1434) |
| * Wreorder: C++ Dialect Options. |
| (line 463) |
| * Wreturn-type: Warning Options. (line 527) |
| * Wripa-opt-mismatch: Warning Options. (line 542) |
| * Wselector: Objective-C and Objective-C++ Dialect Options. |
| (line 171) |
| * Wself-assign: Warning Options. (line 483) |
| * Wself-assign-non-pod: Warning Options. (line 506) |
| * Wsequence-point: Warning Options. (line 437) |
| * Wshadow: Warning Options. (line 1023) |
| * Wshadow-compatible-local: Warning Options. (line 1034) |
| * Wshadow-local: Warning Options. (line 1030) |
| * Wsign-compare: Warning Options. (line 1201) |
| * Wsign-conversion: Warning Options. (line 1208) |
| * Wsign-promo: C++ Dialect Options. |
| (line 561) |
| * Wstack-protector: Warning Options. (line 1526) |
| * Wstrict-aliasing: Warning Options. (line 767) |
| * Wstrict-aliasing=n: Warning Options. (line 775) |
| * Wstrict-null-sentinel: C++ Dialect Options. |
| (line 509) |
| * Wstrict-overflow: Warning Options. (line 808) |
| * Wstrict-prototypes: Warning Options. (line 1248) |
| * Wstrict-selector-match: Objective-C and Objective-C++ Dialect Options. |
| (line 183) |
| * Wsuggest-attribute=: Warning Options. (line 859) |
| * Wsuggest-attribute=const: Warning Options. (line 865) |
| * Wsuggest-attribute=noreturn: Warning Options. (line 865) |
| * Wsuggest-attribute=pure: Warning Options. (line 865) |
| * Wswitch: Warning Options. (line 550) |
| * Wswitch-default: Warning Options. (line 558) |
| * Wswitch-enum: Warning Options. (line 561) |
| * Wsync-nand: Warning Options. (line 570) |
| * Wsystem-headers <1>: Preprocessor Options. |
| (line 153) |
| * Wsystem-headers: Warning Options. (line 887) |
| * Wthread-safety: Warning Options. (line 575) |
| * Wtraditional <1>: Preprocessor Options. |
| (line 106) |
| * Wtraditional: Warning Options. (line 924) |
| * Wtraditional-conversion: Warning Options. (line 1001) |
| * Wtrampolines: Warning Options. (line 898) |
| * Wtrigraphs <1>: Preprocessor Options. |
| (line 94) |
| * Wtrigraphs: Warning Options. (line 611) |
| * Wtype-limits: Warning Options. (line 1093) |
| * Wundeclared-selector: Objective-C and Objective-C++ Dialect Options. |
| (line 191) |
| * Wundef <1>: Preprocessor Options. |
| (line 112) |
| * Wundef: Warning Options. (line 1016) |
| * Wuninitialized: Warning Options. (line 688) |
| * Wunknown-pragmas: Warning Options. (line 755) |
| * Wunsafe-loop-optimizations: Warning Options. (line 1074) |
| * Wunsuffixed-float-constants: Warning Options. (line 1550) |
| * Wunused: Warning Options. (line 681) |
| * Wunused-but-set-parameter: Warning Options. (line 616) |
| * Wunused-but-set-variable: Warning Options. (line 625) |
| * Wunused-function: Warning Options. (line 635) |
| * Wunused-label: Warning Options. (line 640) |
| * Wunused-macros: Preprocessor Options. |
| (line 117) |
| * Wunused-parameter: Warning Options. (line 647) |
| * Wunused-result: Warning Options. (line 654) |
| * Wunused-value: Warning Options. (line 671) |
| * Wunused-variable: Warning Options. (line 659) |
| * Wvariadic-macros: Warning Options. (line 1495) |
| * Wvla: Warning Options. (line 1501) |
| * Wvolatile-register-var: Warning Options. (line 1505) |
| * Wwrite-strings: Warning Options. (line 1137) |
| * x <1>: Preprocessor Options. |
| (line 310) |
| * x: Overall Options. (line 126) |
| * Xassembler: Assembler Options. (line 13) |
| * Xbind-lazy: VxWorks Options. (line 26) |
| * Xbind-now: VxWorks Options. (line 30) |
| * Xlinker: Link Options. (line 184) |
| * Xpreprocessor: Preprocessor Options. |
| (line 25) |
| * Ym: System V Options. (line 26) |
| * YP: System V Options. (line 22) |
| |
| |
| File: gcc.info, Node: Keyword Index, Prev: Option Index, Up: Top |
| |
| Keyword Index |
| ************* |
| |
| [index] |
| * Menu: |
| |
| * ! in constraint: Multi-Alternative. (line 33) |
| * # in constraint: Modifiers. (line 57) |
| * #pragma: Pragmas. (line 6) |
| * #pragma implementation: C++ Interface. (line 39) |
| * #pragma implementation, implied: C++ Interface. (line 46) |
| * #pragma interface: C++ Interface. (line 20) |
| * #pragma, reason for not using: Function Attributes. |
| (line 1767) |
| * $: 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) |
| * * in constraint: Modifiers. (line 62) |
| * + in constraint: Modifiers. (line 12) |
| * -lgcc, use with -nodefaultlibs: Link Options. (line 82) |
| * -lgcc, use with -nostdlib: Link Options. (line 82) |
| * -nodefaultlibs and unresolved references: Link Options. (line 82) |
| * -nostdlib and unresolved references: Link Options. (line 82) |
| * .sdata/.sdata2 references (PowerPC): RS/6000 and PowerPC Options. |
| (line 703) |
| * //: C++ Comments. (line 6) |
| * 0 in constraint: Simple Constraints. (line 127) |
| * < in constraint: Simple Constraints. (line 48) |
| * = in constraint: Modifiers. (line 8) |
| * > in constraint: Simple Constraints. (line 61) |
| * ? in constraint: Multi-Alternative. (line 27) |
| * ?: extensions: Conditionals. (line 6) |
| * ?: side effect: Conditionals. (line 20) |
| * _ in variables in macros: Typeof. (line 46) |
| * __builtin___clear_cache: Other Builtins. (line 329) |
| * __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 548) |
| * __builtin_bswap64: Other Builtins. (line 553) |
| * __builtin_choose_expr: Other Builtins. (line 157) |
| * __builtin_clz: Other Builtins. (line 481) |
| * __builtin_clzl: Other Builtins. (line 499) |
| * __builtin_clzll: Other Builtins. (line 519) |
| * __builtin_constant_p: Other Builtins. (line 197) |
| * __builtin_ctz: Other Builtins. (line 485) |
| * __builtin_ctzl: Other Builtins. (line 503) |
| * __builtin_ctzll: Other Builtins. (line 523) |
| * __builtin_expect: Other Builtins. (line 247) |
| * __builtin_extract_return_address: Return Address. (line 37) |
| * __builtin_ffs: Other Builtins. (line 477) |
| * __builtin_ffsl: Other Builtins. (line 495) |
| * __builtin_ffsll: Other Builtins. (line 515) |
| * __builtin_fpclassify: Other Builtins. (line 6) |
| * __builtin_frame_address: Return Address. (line 51) |
| * __builtin_frob_return_address: Return Address. (line 46) |
| * __builtin_huge_val: Other Builtins. (line 380) |
| * __builtin_huge_valf: Other Builtins. (line 385) |
| * __builtin_huge_vall: Other Builtins. (line 388) |
| * __builtin_huge_valq: X86 Built-in Functions. |
| (line 51) |
| * __builtin_inf: Other Builtins. (line 403) |
| * __builtin_infd128: Other Builtins. (line 413) |
| * __builtin_infd32: Other Builtins. (line 407) |
| * __builtin_infd64: Other Builtins. (line 410) |
| * __builtin_inff: Other Builtins. (line 417) |
| * __builtin_infl: Other Builtins. (line 422) |
| * __builtin_infq: X86 Built-in Functions. |
| (line 47) |
| * __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 433) |
| * __builtin_nand128: Other Builtins. (line 455) |
| * __builtin_nand32: Other Builtins. (line 449) |
| * __builtin_nand64: Other Builtins. (line 452) |
| * __builtin_nanf: Other Builtins. (line 459) |
| * __builtin_nanl: Other Builtins. (line 462) |
| * __builtin_nans: Other Builtins. (line 466) |
| * __builtin_nansf: Other Builtins. (line 470) |
| * __builtin_nansl: Other Builtins. (line 473) |
| * __builtin_object_size: Object Size Checking. |
| (line 6) |
| * __builtin_offsetof: Offsetof. (line 6) |
| * __builtin_parity: Other Builtins. (line 492) |
| * __builtin_parityl: Other Builtins. (line 511) |
| * __builtin_parityll: Other Builtins. (line 531) |
| * __builtin_popcount: Other Builtins. (line 489) |
| * __builtin_popcountl: Other Builtins. (line 507) |
| * __builtin_popcountll: Other Builtins. (line 527) |
| * __builtin_powi: Other Builtins. (line 6) |
| * __builtin_powif: Other Builtins. (line 6) |
| * __builtin_powil: Other Builtins. (line 6) |
| * __builtin_prefetch: Other Builtins. (line 341) |
| * __builtin_return: Constructing Calls. (line 48) |
| * __builtin_return_address: Return Address. (line 11) |
| * __builtin_rx_brk: RX Built-in Functions. |
| (line 11) |
| * __builtin_rx_clrpsw: RX Built-in Functions. |
| (line 14) |
| * __builtin_rx_int: RX Built-in Functions. |
| (line 18) |
| * __builtin_rx_machi: RX Built-in Functions. |
| (line 22) |
| * __builtin_rx_maclo: RX Built-in Functions. |
| (line 27) |
| * __builtin_rx_mulhi: RX Built-in Functions. |
| (line 32) |
| * __builtin_rx_mullo: RX Built-in Functions. |
| (line 37) |
| * __builtin_rx_mvfachi: RX Built-in Functions. |
| (line 42) |
| * __builtin_rx_mvfacmi: RX Built-in Functions. |
| (line 46) |
| * __builtin_rx_mvfc: RX Built-in Functions. |
| (line 50) |
| * __builtin_rx_mvtachi: RX Built-in Functions. |
| (line 54) |
| * __builtin_rx_mvtaclo: RX Built-in Functions. |
| (line 58) |
| * __builtin_rx_mvtc: RX Built-in Functions. |
| (line 62) |
| * __builtin_rx_mvtipl: RX Built-in Functions. |
| (line 66) |
| * __builtin_rx_racw: RX Built-in Functions. |
| (line 70) |
| * __builtin_rx_revw: RX Built-in Functions. |
| (line 74) |
| * __builtin_rx_rmpa: RX Built-in Functions. |
| (line 79) |
| * __builtin_rx_round: RX Built-in Functions. |
| (line 83) |
| * __builtin_rx_sat: RX Built-in Functions. |
| (line 88) |
| * __builtin_rx_setpsw: RX Built-in Functions. |
| (line 92) |
| * __builtin_rx_wait: RX Built-in Functions. |
| (line 96) |
| * __builtin_trap: Other Builtins. (line 271) |
| * __builtin_types_compatible_p: Other Builtins. (line 111) |
| * __builtin_unreachable: Other Builtins. (line 278) |
| * __builtin_va_arg_pack: Constructing Calls. (line 53) |
| * __builtin_va_arg_pack_len: Constructing Calls. (line 76) |
| * __complex__ keyword: Complex. (line 6) |
| * __declspec(dllexport): Function Attributes. |
| (line 259) |
| * __declspec(dllimport): Function Attributes. |
| (line 294) |
| * __extension__: Alternate Keywords. (line 30) |
| * __float128 data type: Floating Types. (line 6) |
| * __float80 data type: Floating Types. (line 6) |
| * __fp16 data type: Half-Precision. (line 6) |
| * __func__ identifier: Function Names. (line 6) |
| * __FUNCTION__ identifier: Function Names. (line 6) |
| * __imag__ keyword: Complex. (line 27) |
| * __int128 data types: __int128. (line 6) |
| * __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 <1>: C++ Volatiles. (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 154) |
| * address of a label: Labels as Values. (line 6) |
| * address_operand: Simple Constraints. (line 158) |
| * alias attribute: Function Attributes. |
| (line 36) |
| * aligned attribute <1>: Type Attributes. (line 31) |
| * aligned attribute <2>: Variable Attributes. |
| (line 23) |
| * aligned attribute: Function Attributes. |
| (line 49) |
| * alignment: Alignment. (line 6) |
| * alloc_size attribute: Function Attributes. |
| (line 69) |
| * alloca: Other Builtins. (line 6) |
| * alloca vs variable-length arrays: Variable Length. (line 26) |
| * Allow nesting in an interrupt handler on the Blackfin processor.: Function Attributes. |
| (line 888) |
| * alternate keywords: Alternate Keywords. (line 6) |
| * always_inline function attribute: Function Attributes. |
| (line 90) |
| * 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 133) |
| * 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 562) |
| * 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 393) |
| * 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 184) |
| * 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 282) |
| * 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) |
| * C1X: Standards. (line 13) |
| * 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) |
| * callee_pop_aggregate_return attribute: Function Attributes. |
| (line 847) |
| * calling functions through the function vector on H8/300, M16C, M32C and SH2A processors: Function Attributes. |
| (line 532) |
| * 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 508) |
| * character set, input: Preprocessor Options. |
| (line 521) |
| * character set, input normalization: Warning Options. (line 1329) |
| * character set, wide execution: Preprocessor Options. |
| (line 513) |
| * 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 1098) |
| * 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 1201) |
| * 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 183) |
| * constants in constraints: Simple Constraints. (line 70) |
| * constraint modifier characters: Modifiers. (line 6) |
| * constraint, matching: Simple Constraints. (line 139) |
| * 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 211) |
| * 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 22) |
| * debugging information options: Debugging Options. (line 6) |
| * decimal floating types: Decimal Float. (line 6) |
| * declaration scope: Incompatibilities. (line 80) |
| * declarations inside expressions: Statement Exprs. (line 6) |
| * declarations, mixed with code: Mixed Declarations. (line 6) |
| * declaring attributes of functions: Function Attributes. |
| (line 6) |
| * declaring static data in C++: Static Definitions. (line 6) |
| * defining static data in C++: Static Definitions. (line 6) |
| * dependencies for make as output: Environment Variables. |
| (line 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 114) |
| * deprecated attribute.: Function Attributes. |
| (line 234) |
| * designated initializers: Designated Inits. (line 6) |
| * designator lists: Designated Inits. (line 94) |
| * designators: Designated Inits. (line 61) |
| * destructor function attribute: Function Attributes. |
| (line 211) |
| * 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 127) |
| * directory options: Directory Options. (line 6) |
| * disinterrupt attribute: Function Attributes. |
| (line 254) |
| * 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 89) |
| * earlyclobber operand: Modifiers. (line 25) |
| * eight bit data on the H8/300, H8/300H, and H8S: Function Attributes. |
| (line 347) |
| * 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 152) |
| * error messages: Warnings and Errors. |
| (line 6) |
| * escaped newlines: Escaped Newlines. (line 6) |
| * exception handler functions on the Blackfin processor: Function Attributes. |
| (line 357) |
| * 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 163) |
| * 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 363) |
| * F in constraint: Simple Constraints. (line 94) |
| * 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 145) |
| * 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 1883) |
| * 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 1140) |
| * format function attribute: Function Attributes. |
| (line 420) |
| * format_arg function attribute: Function Attributes. |
| (line 485) |
| * 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 807) |
| * 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 865) |
| * function, size of pointer to: Pointer Arith. (line 6) |
| * functions called via pointer on the RS/6000 and PowerPC: Function Attributes. |
| (line 761) |
| * functions in arbitrary sections: Function Attributes. |
| (line 6) |
| * functions that are dynamically resolved: Function Attributes. |
| (line 6) |
| * functions that are passed arguments in registers on the 386: Function Attributes. |
| (line 6) |
| * functions that 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 177) |
| * 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 878) |
| * functions which handle memory bank switching: Function Attributes. |
| (line 375) |
| * 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 120) |
| * G in constraint: Simple Constraints. (line 98) |
| * 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 319) |
| * gcc_struct attribute: Variable Attributes. |
| (line 419) |
| * gcov: Debugging Options. (line 370) |
| * 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 95) |
| * Go: G++ and GCC. (line 6) |
| * goto with computed label: Labels as Values. (line 6) |
| * gprof: Debugging Options. (line 300) |
| * grouping options: Invoking GCC. (line 26) |
| * H in constraint: Simple Constraints. (line 98) |
| * half-precision floating point: Half-Precision. (line 6) |
| * 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 218) |
| * hosted environment: Standards. (line 13) |
| * hosted implementation: Standards. (line 13) |
| * hot function attribute: Function Attributes. |
| (line 1085) |
| * 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 81) |
| * i in constraint: Simple Constraints. (line 70) |
| * i386 and x86-64 Windows Options: i386 and x86-64 Windows Options. |
| (line 6) |
| * i386 Options: i386 and x86-64 Options. |
| (line 6) |
| * IA-64 Options: IA-64 Options. (line 6) |
| * IBM RS/6000 and PowerPC Options: RS/6000 and PowerPC Options. |
| (line 6) |
| * identifier names, dollar signs in: Dollar Signs. (line 6) |
| * identifiers, names in assembler code: Asm Labels. (line 6) |
| * ifunc attribute: Function Attributes. |
| (line 648) |
| * ilogb: Other Builtins. (line 6) |
| * ilogbf: Other Builtins. (line 6) |
| * ilogbl: Other Builtins. (line 6) |
| * imaxabs: Other Builtins. (line 6) |
| * implementation-defined behavior, C language: C Implementation. |
| (line 6) |
| * implementation-defined behavior, C++ language: C++ Implementation. |
| (line 6) |
| * implied #pragma implementation: C++ Interface. (line 46) |
| * incompatibilities of GCC: Incompatibilities. (line 6) |
| * increment operators: Bug Criteria. (line 17) |
| * index: Other Builtins. (line 6) |
| * indirect calls on ARM: Function Attributes. |
| (line 751) |
| * indirect calls on MIPS: Function Attributes. |
| (line 773) |
| * 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 140) |
| * interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors: Function Attributes. |
| (line 688) |
| * interrupt service routines on ARM: Function Attributes. |
| (line 703) |
| * interrupt thread functions on fido: Function Attributes. |
| (line 695) |
| * 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 C1X: Standards. (line 13) |
| * ISO C90: Standards. (line 13) |
| * ISO C94: Standards. (line 13) |
| * ISO C95: Standards. (line 13) |
| * ISO C99: Standards. (line 13) |
| * ISO C9X: Standards. (line 13) |
| * ISO support: C Dialect Options. (line 10) |
| * ISO/IEC 9899: Standards. (line 13) |
| * isprint: Other Builtins. (line 6) |
| * ispunct: Other Builtins. (line 6) |
| * isspace: Other Builtins. (line 6) |
| * isupper: Other Builtins. (line 6) |
| * iswalnum: Other Builtins. (line 6) |
| * iswalpha: Other Builtins. (line 6) |
| * iswblank: Other Builtins. (line 6) |
| * iswcntrl: Other Builtins. (line 6) |
| * iswdigit: Other Builtins. (line 6) |
| * iswgraph: Other Builtins. (line 6) |
| * iswlower: Other Builtins. (line 6) |
| * iswprint: Other Builtins. (line 6) |
| * iswpunct: Other Builtins. (line 6) |
| * iswspace: Other Builtins. (line 6) |
| * iswupper: Other Builtins. (line 6) |
| * iswxdigit: Other Builtins. (line 6) |
| * isxdigit: Other Builtins. (line 6) |
| * j0: Other Builtins. (line 6) |
| * j0f: Other Builtins. (line 6) |
| * j0l: Other Builtins. (line 6) |
| * j1: Other Builtins. (line 6) |
| * j1f: Other Builtins. (line 6) |
| * j1l: Other Builtins. (line 6) |
| * Java: G++ and GCC. (line 6) |
| * java_interface attribute: C++ Attributes. (line 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) |
| * keep_interrupts_masked attribute: Function Attributes. |
| (line 624) |
| * keywords, alternate: Alternate Keywords. (line 6) |
| * known causes of trouble: Trouble. (line 6) |
| * l1_data variable attribute: Variable Attributes. |
| (line 330) |
| * l1_data_A variable attribute: Variable Attributes. |
| (line 330) |
| * l1_data_B variable attribute: Variable Attributes. |
| (line 330) |
| * l1_text function attribute: Function Attributes. |
| (line 712) |
| * l2 function attribute: Function Attributes. |
| (line 718) |
| * l2 variable attribute: Variable Attributes. |
| (line 338) |
| * 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) |
| * leaf function attribute: Function Attributes. |
| (line 724) |
| * 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 178) |
| * LK fixed-suffix: Fixed-Point. (line 6) |
| * lk fixed-suffix: Fixed-Point. (line 6) |
| * LL integer suffix: Long Long. (line 6) |
| * llabs: Other Builtins. (line 6) |
| * LLK fixed-suffix: Fixed-Point. (line 6) |
| * llk fixed-suffix: Fixed-Point. (line 6) |
| * LLR fixed-suffix: Fixed-Point. (line 6) |
| * llr fixed-suffix: Fixed-Point. (line 6) |
| * llrint: Other Builtins. (line 6) |
| * llrintf: Other Builtins. (line 6) |
| * llrintl: Other Builtins. (line 6) |
| * llround: Other Builtins. (line 6) |
| * llroundf: Other Builtins. (line 6) |
| * llroundl: Other Builtins. (line 6) |
| * LM32 options: LM32 Options. (line 6) |
| * load address instruction: Simple Constraints. (line 154) |
| * local labels: Local Labels. (line 6) |
| * local variables in macros: Typeof. (line 46) |
| * local variables, specifying registers: Local Reg Vars. (line 6) |
| * locale: Environment Variables. |
| (line 21) |
| * locale definition: Environment Variables. |
| (line 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 738) |
| * 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 242) |
| * macros, inline alternative: Inline. (line 6) |
| * macros, local labels: Local Labels. (line 6) |
| * macros, local variables in: Typeof. (line 46) |
| * macros, statements in expressions: Statement Exprs. (line 6) |
| * macros, types of arguments: Typeof. (line 6) |
| * make: Preprocessor Options. |
| (line 173) |
| * malloc: Other Builtins. (line 6) |
| * malloc attribute: Function Attributes. |
| (line 783) |
| * matching constraint: Simple Constraints. (line 139) |
| * MCore options: MCore Options. (line 6) |
| * member fns, automatically inline: Inline. (line 71) |
| * memchr: Other Builtins. (line 6) |
| * memcmp: Other Builtins. (line 6) |
| * memcpy: Other Builtins. (line 6) |
| * memory references in constraints: Simple Constraints. (line 17) |
| * mempcpy: Other Builtins. (line 6) |
| * memset: Other Builtins. (line 6) |
| * MeP options: MeP Options. (line 6) |
| * Mercury: G++ and GCC. (line 23) |
| * message formatting: Language Independent Options. |
| (line 6) |
| * messages, warning: Warning Options. (line 6) |
| * messages, warning and error: Warnings and Errors. |
| (line 6) |
| * MicroBlaze Options: MicroBlaze Options. (line 6) |
| * middle-operands, omitted: Conditionals. (line 6) |
| * MIPS options: MIPS Options. (line 6) |
| * mips16 attribute: Function Attributes. |
| (line 793) |
| * 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 134) |
| * 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 835) |
| * ms_hook_prologue attribute: Function Attributes. |
| (line 859) |
| * ms_struct: Type Attributes. (line 319) |
| * ms_struct attribute: Variable Attributes. |
| (line 419) |
| * mudflap: Optimize Options. (line 393) |
| * multiple alternative constraints: Multi-Alternative. (line 6) |
| * multiprecision arithmetic: Long Long. (line 6) |
| * n in constraint: Simple Constraints. (line 75) |
| * named address spaces: Named Address Spaces. |
| (line 6) |
| * names used in assembler code: Asm Labels. (line 6) |
| * naming convention, implementation headers: C++ Interface. (line 46) |
| * 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 1329) |
| * NFKC: Warning Options. (line 1329) |
| * NMI handler functions on the Blackfin processor: Function Attributes. |
| (line 893) |
| * no_instrument_function function attribute: Function Attributes. |
| (line 899) |
| * no_split_stack function attribute: Function Attributes. |
| (line 904) |
| * noclone function attribute: Function Attributes. |
| (line 920) |
| * nocommon attribute: Variable Attributes. |
| (line 105) |
| * noinline function attribute: Function Attributes. |
| (line 910) |
| * nomips16 attribute: Function Attributes. |
| (line 793) |
| * non-constant initializers: Initializers. (line 6) |
| * non-static inline function: Inline. (line 85) |
| * nonnull function attribute: Function Attributes. |
| (line 926) |
| * noreturn function attribute: Function Attributes. |
| (line 953) |
| * nothrow function attribute: Function Attributes. |
| (line 995) |
| * o in constraint: Simple Constraints. (line 23) |
| * OBJC_INCLUDE_PATH: Environment Variables. |
| (line 129) |
| * Objective-C <1>: Standards. (line 157) |
| * 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 157) |
| * 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 235) |
| * operand constraints, asm: Constraints. (line 6) |
| * optimize function attribute: Function Attributes. |
| (line 1003) |
| * optimize options: Optimize Options. (line 6) |
| * options to control diagnostics formatting: Language Independent Options. |
| (line 6) |
| * options to control warnings: Warning Options. (line 6) |
| * options, C++: C++ Dialect Options. |
| (line 6) |
| * options, code generation: Code Gen Options. (line 6) |
| * options, debugging: Debugging Options. (line 6) |
| * options, dialect: C Dialect Options. (line 6) |
| * options, directory search: Directory Options. (line 6) |
| * options, GCC command: Invoking GCC. (line 6) |
| * options, grouping: Invoking GCC. (line 26) |
| * options, linking: Link Options. (line 6) |
| * options, Objective-C and Objective-C++: Objective-C and Objective-C++ Dialect Options. |
| (line 6) |
| * options, optimization: Optimize Options. (line 6) |
| * options, order: Invoking GCC. (line 30) |
| * options, preprocessor: Preprocessor Options. |
| (line 6) |
| * order of evaluation, side effects: Non-bugs. (line 196) |
| * order of options: Invoking GCC. (line 30) |
| * OS_main AVR function attribute: Function Attributes. |
| (line 1020) |
| * OS_task AVR function attribute: Function Attributes. |
| (line 1020) |
| * other register constraints: Simple Constraints. (line 163) |
| * output file option: Overall Options. (line 191) |
| * overloaded virtual function, warning: C++ Dialect Options. |
| (line 538) |
| * p in constraint: Simple Constraints. (line 154) |
| * packed attribute: Variable Attributes. |
| (line 145) |
| * parameter forward declaration: Variable Length. (line 59) |
| * Pascal: G++ and GCC. (line 23) |
| * pcs function attribute: Function Attributes. |
| (line 1045) |
| * 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 188) |
| * 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 21) |
| * pragma GCC pop_options: Function Specific Option Pragmas. |
| (line 34) |
| * pragma GCC push_options: Function Specific Option Pragmas. |
| (line 34) |
| * pragma GCC reset_options: Function Specific Option Pragmas. |
| (line 44) |
| * pragma GCC target: Function Specific Option Pragmas. |
| (line 7) |
| * pragma, address: M32C Pragmas. (line 15) |
| * pragma, align: Solaris Pragmas. (line 11) |
| * pragma, call: MeP Pragmas. (line 48) |
| * pragma, coprocessor available: MeP Pragmas. (line 13) |
| * pragma, coprocessor call_saved: MeP Pragmas. (line 20) |
| * pragma, coprocessor subclass: MeP Pragmas. (line 28) |
| * pragma, custom io_volatile: MeP Pragmas. (line 7) |
| * pragma, diagnostic: Diagnostic Pragmas. (line 14) |
| * pragma, disinterrupt: MeP Pragmas. (line 38) |
| * pragma, extern_prefix: Symbol-Renaming Pragmas. |
| (line 20) |
| * 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 1767) |
| * 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 755) |
| * 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 294) |
| * progmem AVR variable attribute: Variable Attributes. |
| (line 314) |
| * promotion of formal parameters: Function Prototypes. |
| (line 6) |
| * pure function attribute: Function Attributes. |
| (line 1063) |
| * push address instruction: Simple Constraints. (line 154) |
| * 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 66) |
| * 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 66) |
| * registers, global allocation: Explicit Reg Vars. (line 6) |
| * registers, global variables in: Global Reg Vars. (line 6) |
| * regparm attribute: Function Attributes. |
| (line 1116) |
| * relocation truncated to fit (ColdFire): M680x0 Options. (line 328) |
| * relocation truncated to fit (MIPS): MIPS Options. (line 199) |
| * 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 463) |
| * reporting bugs: Bugs. (line 6) |
| * resbank attribute: Function Attributes. |
| (line 1148) |
| * 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 1162) |
| * 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) |
| * RX Options: RX Options. (line 6) |
| * s in constraint: Simple Constraints. (line 102) |
| * 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 1171) |
| * save volatile registers on the MicroBlaze: Function Attributes. |
| (line 1176) |
| * 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 22) |
| * scope of declaration: Disappointments. (line 21) |
| * scope of external declarations: Incompatibilities. (line 80) |
| * Score Options: Score Options. (line 6) |
| * search path: Directory Options. (line 6) |
| * section function attribute: Function Attributes. |
| (line 1184) |
| * section variable attribute: Variable Attributes. |
| (line 166) |
| * sentinel function attribute: Function Attributes. |
| (line 1200) |
| * setjmp: Global Reg Vars. (line 66) |
| * setjmp incompatibilities: Incompatibilities. (line 39) |
| * shared strings: Incompatibilities. (line 9) |
| * shared variable attribute: Variable Attributes. |
| (line 211) |
| * 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 1231) |
| * 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 1201) |
| * 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 703) |
| * snprintf: Other Builtins. (line 6) |
| * Solaris 2 options: Solaris 2 Options. (line 6) |
| * SPARC options: SPARC Options. (line 6) |
| * Spec Files: Spec Files. (line 6) |
| * specified registers: Explicit Reg Vars. (line 6) |
| * specifying compiler version and target machine: Target Options. |
| (line 6) |
| * specifying hardware config: Submodel Options. (line 6) |
| * specifying machine version: Target Options. (line 6) |
| * specifying registers for local variables: Local Reg Vars. (line 6) |
| * speed of compilation: Precompiled Headers. |
| (line 6) |
| * sprintf: Other Builtins. (line 6) |
| * SPU options: SPU Options. (line 6) |
| * 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 1133) |
| * 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 1253) |
| * system headers, warnings from: Warning Options. (line 887) |
| * sysv_abi attribute: Function Attributes. |
| (line 835) |
| * 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 1260) |
| * target machine, specifying: Target Options. (line 6) |
| * target options: Target Options. (line 6) |
| * target("abm") attribute: Function Attributes. |
| (line 1287) |
| * target("aes") attribute: Function Attributes. |
| (line 1292) |
| * target("align-stringops") attribute: Function Attributes. |
| (line 1382) |
| * target("altivec") attribute: Function Attributes. |
| (line 1408) |
| * target("arch=ARCH") attribute: Function Attributes. |
| (line 1391) |
| * target("avoid-indexed-addresses") attribute: Function Attributes. |
| (line 1528) |
| * target("cld") attribute: Function Attributes. |
| (line 1353) |
| * target("cmpb") attribute: Function Attributes. |
| (line 1414) |
| * target("cpu=CPU") attribute: Function Attributes. |
| (line 1543) |
| * target("dlmzb") attribute: Function Attributes. |
| (line 1420) |
| * target("fancy-math-387") attribute: Function Attributes. |
| (line 1357) |
| * target("fma4") attribute: Function Attributes. |
| (line 1337) |
| * target("fpmath=FPMATH") attribute: Function Attributes. |
| (line 1399) |
| * target("fprnd") attribute: Function Attributes. |
| (line 1427) |
| * target("friz") attribute: Function Attributes. |
| (line 1519) |
| * target("fused-madd") attribute: Function Attributes. |
| (line 1362) |
| * target("hard-dfp") attribute: Function Attributes. |
| (line 1433) |
| * target("ieee-fp") attribute: Function Attributes. |
| (line 1367) |
| * target("inline-all-stringops") attribute: Function Attributes. |
| (line 1372) |
| * target("inline-stringops-dynamically") attribute: Function Attributes. |
| (line 1376) |
| * target("isel") attribute: Function Attributes. |
| (line 1438) |
| * target("longcall") attribute: Function Attributes. |
| (line 1538) |
| * target("lwp") attribute: Function Attributes. |
| (line 1345) |
| * target("mfcrf") attribute: Function Attributes. |
| (line 1442) |
| * target("mfpgpr") attribute: Function Attributes. |
| (line 1449) |
| * target("mmx") attribute: Function Attributes. |
| (line 1296) |
| * target("mulhw") attribute: Function Attributes. |
| (line 1456) |
| * target("multiple") attribute: Function Attributes. |
| (line 1463) |
| * target("paired") attribute: Function Attributes. |
| (line 1533) |
| * target("pclmul") attribute: Function Attributes. |
| (line 1300) |
| * target("popcnt") attribute: Function Attributes. |
| (line 1304) |
| * target("popcntb") attribute: Function Attributes. |
| (line 1474) |
| * target("popcntd") attribute: Function Attributes. |
| (line 1481) |
| * target("powerpc-gfxopt") attribute: Function Attributes. |
| (line 1487) |
| * target("powerpc-gpopt") attribute: Function Attributes. |
| (line 1493) |
| * target("recip") attribute: Function Attributes. |
| (line 1386) |
| * target("recip-precision") attribute: Function Attributes. |
| (line 1499) |
| * target("sse") attribute: Function Attributes. |
| (line 1308) |
| * target("sse2") attribute: Function Attributes. |
| (line 1312) |
| * target("sse3") attribute: Function Attributes. |
| (line 1316) |
| * target("sse4") attribute: Function Attributes. |
| (line 1320) |
| * target("sse4.1") attribute: Function Attributes. |
| (line 1325) |
| * target("sse4.2") attribute: Function Attributes. |
| (line 1329) |
| * target("sse4a") attribute: Function Attributes. |
| (line 1333) |
| * target("ssse3") attribute: Function Attributes. |
| (line 1349) |
| * target("string") attribute: Function Attributes. |
| (line 1505) |
| * target("tune=TUNE") attribute: Function Attributes. |
| (line 1395) |
| * target("update") attribute: Function Attributes. |
| (line 1468) |
| * target("vsx") attribute: Function Attributes. |
| (line 1511) |
| * target("xop") attribute: Function Attributes. |
| (line 1341) |
| * 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 1572) |
| * TLS: Thread-Local. (line 6) |
| * tls_model attribute: Variable Attributes. |
| (line 235) |
| * 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 282) |
| * 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 46) |
| * union: Unnamed Fields. (line 6) |
| * union, casting to a: Cast to Union. (line 6) |
| * unions: Incompatibilities. (line 146) |
| * unknown pragmas, warning: Warning Options. (line 755) |
| * unresolved references and -nodefaultlibs: Link Options. (line 82) |
| * unresolved references and -nostdlib: Link Options. (line 82) |
| * unused attribute.: Function Attributes. |
| (line 1584) |
| * UR fixed-suffix: Fixed-Point. (line 6) |
| * ur fixed-suffix: Fixed-Point. (line 6) |
| * use_debug_exception_return attribute: Function Attributes. |
| (line 629) |
| * use_shadow_register_set attribute: Function Attributes. |
| (line 620) |
| * used attribute.: Function Attributes. |
| (line 1589) |
| * User stack pointer in interrupts on the Blackfin: Function Attributes. |
| (line 707) |
| * 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 807) |
| * variable addressability on the M32R/D: Variable Attributes. |
| (line 348) |
| * 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 22) |
| * variable-length arrays: Variable Length. (line 6) |
| * variables in specified registers: Explicit Reg Vars. (line 6) |
| * variables, local, in macros: Typeof. (line 46) |
| * variadic macros: Variadic Macros. (line 6) |
| * VAX options: VAX Options. (line 6) |
| * version_id attribute: Function Attributes. |
| (line 1595) |
| * vfprintf: Other Builtins. (line 6) |
| * vfscanf: Other Builtins. (line 6) |
| * visibility attribute: Function Attributes. |
| (line 1605) |
| * VLAs: Variable Length. (line 6) |
| * vliw attribute: Function Attributes. |
| (line 1699) |
| * void pointers, arithmetic: Pointer Arith. (line 6) |
| * void, size of pointer to: Pointer Arith. (line 6) |
| * volatile access <1>: C++ Volatiles. (line 6) |
| * volatile access: Volatiles. (line 6) |
| * volatile applied to function: Function Attributes. |
| (line 6) |
| * volatile read <1>: C++ Volatiles. (line 6) |
| * volatile read: Volatiles. (line 6) |
| * volatile write <1>: C++ 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 1705) |
| * warning for comparison of signed and unsigned values: Warning Options. |
| (line 1201) |
| * warning for overloaded virtual function: C++ Dialect Options. |
| (line 538) |
| * warning for reordering of member initializers: C++ Dialect Options. |
| (line 463) |
| * warning for unknown pragmas: Warning Options. (line 755) |
| * warning function attribute: Function Attributes. |
| (line 165) |
| * warning messages: Warning Options. (line 6) |
| * warnings from system headers: Warning Options. (line 887) |
| * warnings vs errors: Warnings and Errors. |
| (line 6) |
| * weak attribute: Function Attributes. |
| (line 1722) |
| * weakref attribute: Function Attributes. |
| (line 1731) |
| * whitespace: Incompatibilities. (line 112) |
| * X in constraint: Simple Constraints. (line 124) |
| * 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) |
| |
| |
| |
| Tag Table: |
| Node: Top2106 |
| Node: G++ and GCC3879 |
| Node: Standards5948 |
| Node: Invoking GCC18115 |
| Node: Option Summary21866 |
| Node: Overall Options59752 |
| Node: Invoking G++74493 |
| Node: C Dialect Options76016 |
| Node: C++ Dialect Options91096 |
| Node: Objective-C and Objective-C++ Dialect Options116096 |
| Node: Language Independent Options126635 |
| Node: Warning Options129559 |
| Node: Debugging Options198942 |
| Node: Optimize Options249746 |
| Ref: Type-punning305784 |
| Node: Preprocessor Options385195 |
| Ref: Wtrigraphs389293 |
| Ref: dashMF394041 |
| Ref: fdollars-in-identifiers404885 |
| Node: Assembler Options413446 |
| Node: Link Options414248 |
| Ref: Link Options-Footnote-1424606 |
| Node: Directory Options424940 |
| Node: Spec Files431229 |
| Node: Target Options453207 |
| Node: Submodel Options453606 |
| Node: ARC Options455225 |
| Node: ARM Options456415 |
| Node: AVR Options470146 |
| Node: Blackfin Options475724 |
| Node: CRIS Options483672 |
| Node: CRX Options487413 |
| Node: Darwin Options487838 |
| Node: DEC Alpha Options495330 |
| Node: DEC Alpha/VMS Options507246 |
| Node: FR30 Options507820 |
| Node: FRV Options508395 |
| Node: GNU/Linux Options515112 |
| Node: H8/300 Options516373 |
| Node: HPPA Options517440 |
| Node: i386 and x86-64 Options526940 |
| Node: i386 and x86-64 Windows Options558100 |
| Node: IA-64 Options560648 |
| Node: IA-64/VMS Options568666 |
| Node: LM32 Options569221 |
| Node: M32C Options569750 |
| Node: M32R/D Options571040 |
| Node: M680x0 Options574627 |
| Node: M68hc1x Options588634 |
| Node: MCore Options590203 |
| Node: MeP Options591710 |
| Node: MicroBlaze Options595683 |
| Node: MIPS Options598254 |
| Node: MMIX Options626174 |
| Node: MN10300 Options628656 |
| Node: PDP-11 Options630864 |
| Node: picoChip Options632558 |
| Node: PowerPC Options634757 |
| Node: RS/6000 and PowerPC Options634993 |
| Node: RX Options671735 |
| Node: S/390 and zSeries Options677307 |
| Node: Score Options685238 |
| Node: SH Options686066 |
| Node: Solaris 2 Options697205 |
| Node: SPARC Options698725 |
| Node: SPU Options708543 |
| Node: System V Options713547 |
| Node: V850 Options714370 |
| Node: VAX Options717949 |
| Node: VxWorks Options718497 |
| Node: x86-64 Options719652 |
| Node: Xstormy16 Options719870 |
| Node: Xtensa Options720159 |
| Node: zSeries Options724493 |
| Node: Code Gen Options724689 |
| Node: Environment Variables751120 |
| Node: Precompiled Headers759016 |
| Node: C Implementation765215 |
| Node: Translation implementation766878 |
| Node: Environment implementation767452 |
| Node: Identifiers implementation768002 |
| Node: Characters implementation769056 |
| Node: Integers implementation771862 |
| Node: Floating point implementation773687 |
| Node: Arrays and pointers implementation776616 |
| Ref: Arrays and pointers implementation-Footnote-1778051 |
| Node: Hints implementation778175 |
| Node: Structures unions enumerations and bit-fields implementation779641 |
| Node: Qualifiers implementation781627 |
| Node: Declarators implementation783399 |
| Node: Statements implementation783741 |
| Node: Preprocessing directives implementation784068 |
| Node: Library functions implementation786173 |
| Node: Architecture implementation786813 |
| Node: Locale-specific behavior implementation787516 |
| Node: C++ Implementation787821 |
| Node: Conditionally-supported behavior789101 |
| Node: Exception handling789611 |
| Node: C Extensions790020 |
| Node: Statement Exprs794855 |
| Node: Local Labels799368 |
| Node: Labels as Values802347 |
| Ref: Labels as Values-Footnote-1804756 |
| Node: Nested Functions804939 |
| Node: Constructing Calls808872 |
| Node: Typeof813603 |
| Node: Conditionals816918 |
| Node: __int128817809 |
| Node: Long Long818329 |
| Node: Complex819831 |
| Node: Floating Types822402 |
| Node: Half-Precision823540 |
| Node: Decimal Float825722 |
| Node: Hex Floats827589 |
| Node: Fixed-Point828630 |
| Node: Named Address Spaces831924 |
| Node: Zero Length833223 |
| Node: Empty Structures836510 |
| Node: Variable Length836926 |
| Node: Variadic Macros839579 |
| Node: Escaped Newlines841961 |
| Node: Subscripting842800 |
| Node: Pointer Arith843523 |
| Node: Initializers844091 |
| Node: Compound Literals844587 |
| Node: Designated Inits846762 |
| Node: Case Ranges850417 |
| Node: Cast to Union851100 |
| Node: Mixed Declarations852196 |
| Node: Function Attributes852702 |
| Node: Attribute Syntax933862 |
| Node: Function Prototypes944308 |
| Node: C++ Comments946089 |
| Node: Dollar Signs946608 |
| Node: Character Escapes947073 |
| Node: Variable Attributes947367 |
| Ref: MeP Variable Attributes962693 |
| Ref: i386 Variable Attributes964654 |
| Node: Type Attributes970347 |
| Ref: MeP Type Attributes984088 |
| Ref: i386 Type Attributes984362 |
| Ref: PowerPC Type Attributes985202 |
| Ref: SPU Type Attributes986064 |
| Node: Alignment986355 |
| Node: Inline987729 |
| Node: Volatiles992713 |
| Node: Extended Asm995608 |
| Ref: Example of asm with clobbered asm reg1001697 |
| Ref: Extended asm with goto1011464 |
| Node: Constraints1019199 |
| Node: Simple Constraints1020283 |
| Node: Multi-Alternative1027604 |
| Node: Modifiers1029321 |
| Node: Machine Constraints1032215 |
| Node: Asm Labels1070859 |
| Node: Explicit Reg Vars1072535 |
| Node: Global Reg Vars1074143 |
| Node: Local Reg Vars1078693 |
| Node: Alternate Keywords1081134 |
| Node: Incomplete Enums1082620 |
| Node: Function Names1083377 |
| Node: Return Address1085539 |
| Node: Vector Extensions1089092 |
| Node: Offsetof1093498 |
| Node: Atomic Builtins1094312 |
| Node: Object Size Checking1099690 |
| Node: Other Builtins1105118 |
| Node: Target Builtins1131798 |
| Node: Alpha Built-in Functions1132722 |
| Node: ARM iWMMXt Built-in Functions1135721 |
| Node: ARM NEON Intrinsics1142440 |
| Node: Blackfin Built-in Functions1348640 |
| Node: FR-V Built-in Functions1349254 |
| Node: Argument Types1350113 |
| Node: Directly-mapped Integer Functions1351869 |
| Node: Directly-mapped Media Functions1352951 |
| Node: Raw read/write Functions1359983 |
| Node: Other Built-in Functions1360895 |
| Node: X86 Built-in Functions1362084 |
| Node: MIPS DSP Built-in Functions1407220 |
| Node: MIPS Paired-Single Support1419667 |
| Node: MIPS Loongson Built-in Functions1421168 |
| Node: Paired-Single Arithmetic1427686 |
| Node: Paired-Single Built-in Functions1428632 |
| Node: MIPS-3D Built-in Functions1431302 |
| Node: picoChip Built-in Functions1436677 |
| Node: Other MIPS Built-in Functions1438043 |
| Node: PowerPC AltiVec/VSX Built-in Functions1438567 |
| Node: RX Built-in Functions1549225 |
| Node: SPARC VIS Built-in Functions1553235 |
| Node: SPU Built-in Functions1554914 |
| Node: Target Format Checks1556696 |
| Node: Solaris Format Checks1557128 |
| Node: Darwin Format Checks1557554 |
| Node: Pragmas1558381 |
| Node: ARM Pragmas1559091 |
| Node: M32C Pragmas1559694 |
| Node: MeP Pragmas1560768 |
| Node: RS/6000 and PowerPC Pragmas1562837 |
| Node: Darwin Pragmas1563578 |
| Node: Solaris Pragmas1564645 |
| Node: Symbol-Renaming Pragmas1565806 |
| Node: Structure-Packing Pragmas1568440 |
| Node: Weak Pragmas1570090 |
| Node: Diagnostic Pragmas1570824 |
| Node: Visibility Pragmas1573852 |
| Node: Push/Pop Macro Pragmas1574604 |
| Node: Function Specific Option Pragmas1575577 |
| Node: Unnamed Fields1577841 |
| Node: Thread-Local1580079 |
| Node: C99 Thread-Local Edits1582186 |
| Node: C++98 Thread-Local Edits1584198 |
| Node: Binary constants1587643 |
| Node: C++ Extensions1588314 |
| Node: C++ Volatiles1589962 |
| Node: Restricted Pointers1592322 |
| Node: Vague Linkage1593920 |
| Node: C++ Interface1597582 |
| Ref: C++ Interface-Footnote-11601879 |
| Node: Template Instantiation1602016 |
| Node: Bound member functions1609028 |
| Node: C++ Attributes1610571 |
| Node: Namespace Association1612229 |
| Node: Type Traits1613643 |
| Node: Java Exceptions1619998 |
| Node: Deprecated Features1621395 |
| Node: Backwards Compatibility1624360 |
| Node: Objective-C1625718 |
| Node: GNU Objective-C runtime API1626327 |
| Node: Modern GNU Objective-C runtime API1627334 |
| Node: Traditional GNU Objective-C runtime API1629771 |
| Node: Executing code before main1631393 |
| Node: What you can and what you cannot do in +load1634131 |
| Node: Type encoding1636521 |
| Node: Legacy type encoding1641597 |
| Node: @encode1642688 |
| Node: Method signatures1643229 |
| Node: Garbage Collection1645224 |
| Node: Constant string objects1647858 |
| Node: compatibility_alias1650366 |
| Node: Exceptions1651088 |
| Node: Synchronization1653799 |
| Node: Fast enumeration1654983 |
| Node: Using fast enumeration1655295 |
| Node: c99-like fast enumeration syntax1656506 |
| Node: Fast enumeration details1657209 |
| Node: Fast enumeration protocol1659550 |
| Node: Messaging with the GNU Objective-C runtime1662702 |
| Node: Dynamically registering methods1664073 |
| Node: Forwarding hook1665764 |
| Node: Compatibility1668803 |
| Node: Gcov1675370 |
| Node: Gcov Intro1675903 |
| Node: Invoking Gcov1678621 |
| Node: Gcov and Optimization1691587 |
| Node: Gcov Data Files1694242 |
| Node: Cross-profiling1695382 |
| Node: Trouble1697233 |
| Node: Actual Bugs1698718 |
| Node: Cross-Compiler Problems1699174 |
| Node: Interoperation1699588 |
| Node: Incompatibilities1706725 |
| Node: Fixed Headers1714876 |
| Node: Standard Libraries1716539 |
| Node: Disappointments1717911 |
| Node: C++ Misunderstandings1722269 |
| Node: Static Definitions1723080 |
| Node: Name lookup1724133 |
| Ref: Name lookup-Footnote-11728911 |
| Node: Temporaries1729098 |
| Node: Copy Assignment1731074 |
| Node: Non-bugs1732881 |
| Node: Warnings and Errors1743388 |
| Node: Bugs1745152 |
| Node: Bug Criteria1745716 |
| Node: Bug Reporting1747926 |
| Node: Service1748147 |
| Node: Contributing1748966 |
| Node: Funding1749706 |
| Node: GNU Project1752195 |
| Node: Copying1752841 |
| Node: GNU Free Documentation License1790369 |
| Node: Contributors1815506 |
| Node: Option Index1852375 |
| Node: Keyword Index2032683 |
| |
| End Tag Table |